You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Ramses has a length unit called unit_l (cgs), e.g. ds.parameters['unit_l']
This is the correct length unit for ramses that feeds into all derived units (densities, pressures, energies, velocities).
Similarly it has unit_t for time etc...
The yt code_length unit (for converting from code units) does not match this unless the boxlen=1
Code for reproduction
Read in any ramses dataset where boxlen !=1,
e.g.
ds=yt.load("output_00001/info_00001.txt")
>>> x=ds.arr(1,"code_length")
>>> x.in_cgs()
YTArray(9.87424e+21) cm
>>> ds.parameters("unit_l")
3.0857e+21
These differ by boxlen (in this case 3.2).
This means that any derived units a user makes from yt's code units are broken and wrong.
e.g. If you have a new energy variable in code units and want to set it up the following will
lead to incorrect results.
Ramses sometimes uses a unit of boxlen*unit_l for some distance variables.
This is not the code length unit. yt should recognize that the units of some position data
for ramses datasets is not ramses code length units but fractions of boxlen x unit_l and avoid having
a broken code_length.
Right now there seems to be some kind of internal hack so that units for pressure and so on in yt
and calculated using the Ramses actual length unit ('unit_l') and then the code_length is set to be
inconsistent with that so all those units cannot be reproduced using combinations of code_length,
code_time and code_mass. This is a nasty gotcha for anyone trying to use yt and ramses.
A general solution is to set the units for position data appropriately, not
to break something so fundamental as the code_length.
The text was updated successfully, but these errors were encountered:
Hi, and welcome to yt! Thanks for opening your first issue. We have an issue template that helps us to gather relevant information to help diagnosing and fixing the issue.
#2800 # Bug report
Bug summary
Ramses has a length unit called unit_l (cgs), e.g. ds.parameters['unit_l']
This is the correct length unit for ramses that feeds into all derived units (densities, pressures, energies, velocities).
Similarly it has unit_t for time etc...
The yt code_length unit (for converting from code units) does not match this unless the boxlen=1
Code for reproduction
Read in any ramses dataset where boxlen !=1,
e.g.
These differ by boxlen (in this case 3.2).
This means that any derived units a user makes from yt's code units are broken and wrong.
e.g. If you have a new energy variable in code units and want to set it up the following will
lead to incorrect results.
Ramses sometimes uses a unit of boxlen*unit_l for some distance variables.
This is not the code length unit. yt should recognize that the units of some position data
for ramses datasets is not ramses code length units but fractions of boxlen x unit_l and avoid having
a broken code_length.
Right now there seems to be some kind of internal hack so that units for pressure and so on in yt
and calculated using the Ramses actual length unit ('unit_l') and then the code_length is set to be
inconsistent with that so all those units cannot be reproduced using combinations of code_length,
code_time and code_mass. This is a nasty gotcha for anyone trying to use yt and ramses.
A general solution is to set the units for position data appropriately, not
to break something so fundamental as the code_length.
The text was updated successfully, but these errors were encountered: