<div dir="ltr">When I remove bbox and base_unit I get reasonable values:<div><br></div><div>







<p class=""> --> Doing dimension: 512</p><p class=""></p>
<p class="">        == Mass density ==</p>
<p class="">   --- Max:  2.366e-22 [g/cm^-3]</p>
<p class="">   --- Min:  0.000e+00 [g/cm^-3]</p>
<p class="">   --- Mean: 1.763e-30 [g/cm^-3]</p>
<p class="">        == Number density ==</p>
<p class="">   --- Max:  1.158e+02 [cm^-3]</p>
<p class="">   --- Min:  0.000e+00 [cm^-3]</p>
<p class="">   --- Mean: 8.627e-07 [cm^-3]</p><p class="">So it appears from the sane default it just does the conversion correctly? Can yt give you estimates for the critical/mean etc. density for a given redshift from the header information or do I have to do that separately to confirm.</p>
<p class="">BG</p></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jul 2, 2014 at 7:48 AM, Matthew Turk <span dir="ltr"><<a href="mailto:matthewturk@gmail.com" target="_blank">matthewturk@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On Wed, Jul 2, 2014 at 1:06 AM, Nathan Goldbaum <<a href="mailto:nathan12343@gmail.com">nathan12343@gmail.com</a>> wrote:<br>

><br>
> On Tue, Jul 1, 2014 at 4:31 PM, Nathan Goldbaum <<a href="mailto:nathan12343@gmail.com">nathan12343@gmail.com</a>><br>
> wrote:<br>
>><br>
>> Hi Brendan,<br>
>><br>
>> Not sure exactly what's happening.  In general it's difficult to remotely<br>
>> debug something like this without a simple test case that one of us can run<br>
>> locally.  Can you perhaps make a test that illustrates the issue using one<br>
>> of the datasets on <a href="http://yt-project.org/data" target="_blank">yt-project.org/data</a>?<br>
>><br>
>><br>
>> On Tue, Jul 1, 2014 at 3:05 PM, Brendan Griffen<br>
>> <<a href="mailto:brendan.f.griffen@gmail.com">brendan.f.griffen@gmail.com</a>> wrote:<br>
>>><br>
>>> I have made a mesh using covering_grid:<br>
>>><br>
>>> pf = load(basepath+ext+'.0.hdf5', unit_base = unit_base, bounding_box =<br>
>>> bbox)<br>
>>><br>
>>> unit_base = {'UnitLength_in_cm'         : 3.08568e+21,<br>
>>>              'UnitMass_in_g'            :   1.989e+43,<br>
>>>              'UnitVelocity_in_cm_per_s' :      100000}<br>
>>><br>
>><br>
>> FWIW, you shouldn't need to set the units or the bbox by hand, yt can read<br>
>> this data from the hdf5 file.<br>
><br>
><br>
> Hmm, looks like I was a little hasty earlier.  This statement is based on<br>
> the OWLS data format, which is a little more descriptive than the default<br>
> gadget hdf5 data format.  In particular, units and bounding box information<br>
> are written to disk along with the particle data in the hdf5 files.<br>
><br>
> If your dataset acts like the public Gadget distribution, you will need to<br>
> provide both the bbox and the unit information.<br>
<br>
</div>For cosmological Gadget simulations, it will set "sane defaults" and<br>
it knows how to get the bbox information by looking at the header<br>
"BoxSize" value.  These defaults are:<br>
<br>
 * Length => 1.0 Mpc/h (comoving)<br>
 * Velocity => 1e5 cm/s (proper)<br>
 * Mass => 1e10 Msun / h<br>
<br>
I think these came from the Gadget manual.<br>
<br>
-Matt<br>
<div class="HOEnZb"><div class="h5"><br>
><br>
>><br>
>><br>
>>><br>
>>> In [3]: bbox<br>
>>><br>
>>> Out[3]:<br>
>>><br>
>>> array([[   0.,  100.],<br>
>>><br>
>>>        [   0.,  100.],<br>
>>><br>
>>>        [   0.,  100.]])<br>
><br>
><br>
> This might be the issue, depending on what units the bbox is interpreted to<br>
> be in. For what it's worth, the OWLS dataset on <a href="http://yt-project.org/data" target="_blank">yt-project.org/data</a> seems to<br>
> be a 25 comoving megaparsec / h box:<br>
><br>
> $ yt load snapshot_033/snap_033.0.hdf5<br>
> IPython 2.1.0 -- An enhanced Interactive Python.<br>
> ?         -> Introduction and overview of IPython's features.<br>
> %quickref -> Quick reference.<br>
> help      -> Python's own help system.<br>
> object?   -> Details about 'object', use 'object??' for extra details.<br>
><br>
> In [1]: ds = yt.load('snapshot_033/snap_033.0.hdf5')<br>
><br>
> In [2]: ds.domain_left_edge<br>
> Out[1]: YTArray([ 0.,  0.,  0.]) code_length<br>
><br>
> In [3]: ds.domain_right_edge<br>
> Out[2]: YTArray([ 25.,  25.,  25.]) code_length<br>
><br>
> In [4]: ds.length_unit<br>
> Out[3]: 3.085678e+24 cmcm/h<br>
><br>
><br>
>>><br>
>>> ndim = 512<br>
>>><br>
>>> level = int(math.log(ndim,2))<br>
>>><br>
>>> cg = pf.covering_grid(level=level,<br>
>>> left_edge=[0,0,0],dims=[ndim,ndim,ndim])<br>
>>><br>
>>> arr = cg['deposit', 'all_cic']<br>
>>><br>
>>> When I do arr.mean() etc. I get the output:<br>
>>><br>
>>>  --> Doing dimension: 512<br>
>>><br>
>>>         == Mass density ==<br>
>>><br>
>>>    --- Max:  2.367e-13 [g/cm^-3]<br>
>>><br>
>>>    --- Min:  0.000e+00 [g/cm^-3]<br>
>>><br>
>>>    --- Mean: 1.764e-21 [g/cm^-3]<br>
>>><br>
>>>         == Number density ==<br>
>>><br>
>>>    --- Max:  1.158e+11 [cm^-3]<br>
>>><br>
>>>    --- Min:  0.000e+00 [cm^-3]<br>
>>><br>
>>>    --- Mean: 8.630e+02 [cm^-3]<br>
>>><br>
>>> Written out mesh:<br>
>>> /bigbang/data/bgriffen/c2ray/cicfiles/parent/512/density/z0.000.dat<br>
>>><br>
>>> I thought it returns the mesh in g/cm^3. Compared to just using the<br>
>>> particles number, box width and particle mass I get (mass & number density):<br>
>>><br>
>>> orig_mass =<br>
>>> (head.massarr[1]*10**10*head.nall[1]/head.hubble)/(head.boxwidth/head.hubble)**3<br>
>>><br>
>>> # just total_mass/total_volume where "head" => header info of HDF5 gadget<br>
>>> snapshot<br>
>>><br>
>>> In [29]: orig_mass*MsolMpc3_to_gcm3<br>
>>><br>
>>> Out[29]: 2.701e-30<br>
>>><br>
>>> In [30]: orig_mass*MsolMpc3_to_gcm3*coeff<br>
>>><br>
>>> Out[30]: 1.321e-06<br>
>>><br>
>>> These seem reasonable but the values back from yt don't. Can anyone<br>
>>> confirm the yt units of the mesh returned? Does it take care of hubble<br>
>>> parameter as read from block? Though this would only account for some minor<br>
>>> discrepancy - it is orders of magnitude off at this stage.<br>
><br>
> yt should detect your dataset as being cosmological and apply the<br>
> appropriate scaling factors.<br>
><br>
> That said I don't have a cosmological gadget hdf5 dataset to test with, so I<br>
> can't easily do an apples-to-apples comparison with what you're trying to<br>
> accomplish.<br>
><br>
> My best advice would be to look at the code in the Gadget frontend using a<br>
> debugger and try to figure out what's going wrong. We haven't had a large<br>
> number of users for the gadget frontend yet so it's likely there's a lot of<br>
> room for improvement. Patches are more than welcome.<br>
><br>
> If anyone happens to have a reasonably sized (< 1 GB) cosomological gadget<br>
> hdf5 dataset, it would be an excellent addition to <a href="http://yt-project.org/data" target="_blank">yt-project.org/data</a>.<br>
><br>
>>><br>
>>> Thanks.<br>
>>><br>
>>> Brendan<br>
>>><br>
>>><br>
>>> _______________________________________________<br>
>>> yt-users mailing list<br>
>>> <a href="mailto:yt-users@lists.spacepope.org">yt-users@lists.spacepope.org</a><br>
>>> <a href="http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org" target="_blank">http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org</a><br>
>>><br>
>><br>
><br>
><br>
> _______________________________________________<br>
> yt-users mailing list<br>
> <a href="mailto:yt-users@lists.spacepope.org">yt-users@lists.spacepope.org</a><br>
> <a href="http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org" target="_blank">http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org</a><br>
><br>
_______________________________________________<br>
yt-users mailing list<br>
<a href="mailto:yt-users@lists.spacepope.org">yt-users@lists.spacepope.org</a><br>
<a href="http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org" target="_blank">http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org</a><br>
</div></div></blockquote></div><br></div>