Re: [yt-users] fields in ghost zones

Hi David, hi Greg, your guess was totally right. I was computing with 64 bits and writing with 32 bits only. I fixed it and restarting Enzo worked well. Great ! Now, I can get back to Greg's suggestion which was using the restarting capability of Enzo instead of reading an HDF5 in my routines. That would make my code much lighter. However, I need to change a few things and would like to have your opinion about it. I want to: - change some global parameters like StopCycle, CycleDataDump, GlobalDir,... Would it work if I only edit the files DDnnnn/CommonEnvelopennnn ? Wouldn't it create a conflict somewhere ? - keep all BaryonFields the same except the velocity that I need to set up to 0. Is there an easy way to do that ? Thanks for your help, JC David Collins a écrit :

...

The issue is I can't trust any simulation done with restarting Enzo. Look at

I wouldn't be so sure that the solution you propose isn't going to suffer from the same problems that you see with restarting. The restarting machinery doesn't do anything fancy, there aren't many places for errors to creep in there. So baring a few things, this is potentially a deeper issue.

One thing to check, which you may have done already, is to ensure that you're writing with the same precision that you're computing with. Ensure that the top 5 things in make show-config are all 64 (or 32, if you must) CONFIG_PRECISION: 64 CONFIG_PARTICLES: 64 CONFIG_INTEGERS: 64 CONFIG_INITS: 64 CONFIG_IO: 64 (Inits doesn't matter for you, but the last one, CONFIG_IO, is important)

Have you checked that restarting without changing anything at all gives different answers? What compiler optimizations are you using? Try with -O1 or -O0, sometimes more aggressive compiler options can change the answer.

d.

...

those two plots: http://drop.io/0etjfmc. I don't want to bother you with too many details but they represent the separation between my two particles - the core of the RGB star and the compact companion.

The first run was with dumping every 80 cycles - dumping based on CycleSkip. It stopped at dumping #196. I restarted it and got data #197, #198,...Then, I wanted to check that restarting did not mess things up, so I run the same sim again but with a dumping frequency twice smaller. So data #98 and #99 correspond to the same cycle as file #196 and #198 respectively. Files #98 and #196 are exactly the same (which is expected) but #99 and #198 are not. They are slightly different and lead at the end to a unphysical behavior - the companion bouncing outwards instead of sinking deeper.

I don't what is causing that, may be the new structure of particles I am using. Has anyone already had that kind of problem ? I will inspect the data at some point in the future but in the meantime, I cannot restart Enzo.

Cheers,

JC

Greg Bryan a écrit :

Or if you just want to read the data directly back in, why not do a restart ("enzo -r")?

Greg

On Jun 2, 2010, at 3:36 PM, David Collins wrote:

Hi, JC--

Would it be easier to skip YT all together, and just have your problem generator read the HDF5 file produced by the 1d run directly? This would streamline your processes, and you wouldn't have the noise incurred by both the ASCII file format and the two units conversions.

I would probably approach your task by looping over only the active zones in enzo, and incrementing an extra counter.

int counter = 0; for(int field=0;field

This code snippit came from the wiki page on Baryon access, for future reference: http://lca.ucsd.edu/projects/enzo/wiki/Tutorials/BaryonFieldAccess

Does that help? d.

On Wed, Jun 2, 2010 at 12:07 PM, Jean-Claude Passy wrote:

Hi Matt,

I will try to explain what my goal is. I have a 1D profile of a star that is physically at the equilibrium. Regarding the problem initialization, I set up the density and the total specific energy fields according to the model, velocities equal 0. However, the star is not numerically stable so I have to relax it. Therefore, I divide the velocity by 2 at each timestep, and I let Enzo run for a few dynamical times. Then, I read the last data dump and create an relaxed_model.dat:

########################################################## region = pf.h.region([0.5, 0.5, 0.5], [0.0, 0.0, 0.0], [1.0, 1.0, 1.0]) output = 'relaxed_model.dat' f = open(output,'w') print >>f, '# Grid Index rho pressure' density = region["Density"] pressure = region["Pressure"] size = NP.size(density) for i in range(0,size,1): dtmp = density[i] ptmp = pressure[i] print >>f, "0", i, '%06e' % dtmp, '%06e' % ptmp ##########################################################

so I end up with a file like this:

########################################################## # Restart file for only one grid # Grid Index rho pressure 0 0 5.099011e-10 2.568020e+05 0 1 5.099011e-10 2.568020e+05 0 2 5.099011e-10 2.568020e+05 ... ########################################################## Finally, I read index, density, pressure from that previous file and do:

########################################################## for (k = 0; k < GridDimension[2]; k++) for (j = 0; j < GridDimension[1]; j++) for (i = 0; i < GridDimension[0]; i++) { index = i + GridDimension[0]*(j + GridDimension[1]*k); density /= DensityUnits; pressure /= PressureUnits; BaryonField[0][index] = density; BaryonField[1][index] = pressure / ((Gamma - 1.0) * density); ########################################################## The problem is GridDimensions contain the ghost zones so the variable index does not match with the actual index read in the file relaxed_model.dat. That is why I wanted to have that file values for the ghost zones as well.

Does it make sense ? Do you have any suggestion ?

Thanks for your help,

JC

Matthew Turk a écrit :

Hi Jean-Claude,

There are a couple aspects to this. The first is that Enzo doesn't output the ghost zones -- so any ghost zones handled inside yt are generated by yt. Were Enzo to output the ghost zones, we would probably be able to handle this, but it does not.

Derived fields can depend on the generation of ghost zones, but keep in mind that these are ghost zones generated by yt. These ghost zones are constructed in a similar manner to how Enzo generates them, but there may be minor differences. You can manually inspect ghost zones on a *grid* by calling retrieve_ghost_zones on that grid.

If you could tell us a bit more about your goal, maybe we could help out a bit more?

-Matt

On Wed, Jun 2, 2010 at 9:32 AM, Jean-Claude Passy wrote:

Dear all,

in order to set up my simulation, I need to access the values of certain fields in the ghost zones. If I do something like:

pf = load(data) region = pf.h.region(...) x = region[field]

x contains the values of field for the physical grid only. Is there a way I can get the same 1D-array but with the ghost zones included as well ?

Thanks for your help,

Jean-Claude

_______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org

_______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org

-- Sent from my Stone Tablet and carried by my Pterodactyl. _______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org

_______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org

_______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org