<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Hi David, hi Greg,<br>
<br>
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 !<br>
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:<br>
- 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 ?<br>
- keep all BaryonFields the same except the velocity that I need to
set up to 0. Is there an easy way to do that ?<br>
<br>
Thanks for your help,<br>
<br>
JC<br>
<br>
David Collins a écrit :
<blockquote
cite="mid:AANLkTilbYMQ8uTyNxulR-m9ERLbJ2ddw87MBhjZ6kX9s@mail.gmail.com"
type="cite">
<blockquote type="cite">
<pre wrap="">The issue is I can't trust any simulation done with restarting Enzo. Look at
</pre>
</blockquote>
<pre wrap=""><!---->
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.
</pre>
<blockquote type="cite">
<pre wrap="">those two plots: <a class="moz-txt-link-freetext" href="http://drop.io/0etjfmc">http://drop.io/0etjfmc</a>. 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<NumberOfBaryonFields;field++)
for(int k=GridStartIndex[2];k<=GridEndIndex[2]; k++)
for(int j=GridStartIndex[1];j<=GridEndIndex[1]; j++)
for(int i=GridStartIndex[0];i<=GridEndIndex[0]; i++){
index = i + GridDimension[0]*(j + GridDimension[1]*k);
BaryonField[ DensNum ][ i ] = DensityFromFile[ counter ];
counter++
}
This code snippit came from the wiki page on Baryon access, for future
reference:
<a class="moz-txt-link-freetext" href="http://lca.ucsd.edu/projects/enzo/wiki/Tutorials/BaryonFieldAccess">http://lca.ucsd.edu/projects/enzo/wiki/Tutorials/BaryonFieldAccess</a>
Does that help?
d.
On Wed, Jun 2, 2010 at 12:07 PM, Jean-Claude Passy
<a class="moz-txt-link-rfc2396E" href="mailto:jcpassy@gmail.com"><jcpassy@gmail.com></a> 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
<a class="moz-txt-link-rfc2396E" href="mailto:jcpassy@gmail.com"><jcpassy@gmail.com></a> 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
<a class="moz-txt-link-abbreviated" href="mailto:yt-users@lists.spacepope.org">yt-users@lists.spacepope.org</a>
<a class="moz-txt-link-freetext" href="http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org">http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org</a>
_______________________________________________
yt-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:yt-users@lists.spacepope.org">yt-users@lists.spacepope.org</a>
<a class="moz-txt-link-freetext" href="http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org">http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org</a>
--
Sent from my Stone Tablet and carried by my Pterodactyl.
_______________________________________________
yt-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:yt-users@lists.spacepope.org">yt-users@lists.spacepope.org</a>
<a class="moz-txt-link-freetext" href="http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org">http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org</a>
_______________________________________________
yt-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:yt-users@lists.spacepope.org">yt-users@lists.spacepope.org</a>
<a class="moz-txt-link-freetext" href="http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org">http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org</a>
_______________________________________________
yt-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:yt-users@lists.spacepope.org">yt-users@lists.spacepope.org</a>
<a class="moz-txt-link-freetext" href="http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org">http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org</a>
</pre>
</blockquote>
<pre wrap=""><!---->
</pre>
</blockquote>
</body>
</html>