Meeting Update 0624

I've redone some of the tests mentioned last week, all from frame 0 (some of the runs in the table I posted last week are from restarts). This is what I found:

res accrete? second particle created?
80+1 yes no
80+2 yes no
80+3 yes no
80+4 no yes
80+5 no yes
160+1 yes no
160+2 yes no
160+3 no yes
160+4 no yes
320+0 yes no
320+1 no yes
320+2 no yes
320+3 no yes



The 80+4, 80+5 runs last week that worked are restarts from frame 50 (the frame right before particle creation) of a previous 80 base grid run. From the new runs, it looks like our issue is entirely on resolution: anything beyond 640 effective resolution cannot accrete after creating the first particle, and will create more particles to "compensate" that. The old restart runs are done on bluestreak, the starting and finishing runs looks like:

http://www.pas.rochester.edu/~shuleli/0603/frame51.png

Particle mass dependence I then went on and did a few tests with switching between Federrath and Krumholz. The idea is to use Federrath for the first few frames after the particle is created, then switch to Krumholz to prevent "explosion". However, the result shows that at 80+5 and 160+4 resolution, even if we switch to Krumholz after particle mass grows to 10 (10% of initial cloud), the particle fails to accrete.

Bluestreak performance issue. I was out of town since last Thursday till Sunday, but I did manage to get a reservation on bluestreak last Saturday and did some runs. I did two runs on bluestreak featuring essentially the same setup: using frame 51 from an old run and 80+4 setup, both run 20 frames (to frame 71). Stampede took 6 hours on 1024 cores, bluestreak took almost full 24 hours reservation time on 8192 cores. The full simulation is about 200 frames, with frames 50 to 150 more "intensive". Bluestreak needs nearly 10 days to finish one entire run, stampede needs about 2 days on 1024 cores. The output chombo files are of size 2.5GB, and I've seen the old BGP dealing with such problem size much much faster. I think the valid option now is to use Kraken for these runs (2048 cores estimated 2 days per run).

Comments

No comments.