[yt-users] troubles with derived field: 1+1 is not equal to 2

Antoine Strugarek strugarek at ASTRO.UMontreal.CA
Fri Aug 8 11:32:21 PDT 2014


Hi Nathan,


Le 2014-08-08 à 13:22 , Nathan Goldbaum <nathan12343 at gmail.com> a écrit :

> 
> 
> 
> On Fri, Aug 8, 2014 at 4:31 AM, Antoine Strugarek <strugarek at astro.umontreal.ca> wrote:
> Hi Nathan and Andrew,
> 
> Many thanks for your help, the fix from Andrew indeed fixed my problem!
> 
> Excellent!  Glad to hear things are working now.  Hopefully we will have Andrew's fix merged in soon.
>  
> Nathan, originally I wanted to use the geometrical field that were automatically computed by yt, but in my case the cylindrical coordinates are not correct. They do not use the shifted version of the original axes, meaning that it seems they supposed the origin (0,0,0) was at the bottom left of the simulation box. I’m not sure if this is the expected behaviour when reading my data set, but I had to recompute them anyway to derive my fields.
> 
> By default yt uses coordinate system the simulation was run with. Is it not doing that in this case?
> 
> You should be able to supply parameters to the coordinate system using a field parameter: http://yt-project.org/docs/3.0/analyzing/fields.html#field-parameters
> 
> In yt 3.0 both SlicePlot and ProjectionPlot take field parameters as keyword arguments.  You can also create a custom data object (e.g. ds.slice, ds.proj), set your field parameters, and then use the to_pw method to get back a SlicePlot or ProjectionPlot created using your custom data source.
>  

I would be glad to use this but I’m not sure I quite understand how to. Ideally what I first tried using yt is to (a) do a load and (b) check the various fields that were automatically computed (cylindrical_r, spherical_r, radius, etc…). When I check the value of the parameter ‘center’ right after doing a load and doing ad=ds.all_data(), it is indeed set to the center of my grid (in my case, the point [20,20,20] since my cube is [0,40]^3. The axes are correct for my slices (e.g., x goes from -20 to 20 as it should be) and the field (‘index’,’radius’) indeed corresponds to the spherical radius. Though the fields label ‘cylindrical_*’ and ’spherical_*’ are not correct and seem to use the upper right corner of my simulation box as the ‘center’ (as if the ‘center’ parameter was applied twice to compute them?). I don’t know if it’s a bug in my chombo file, or a bug in the chombo frontend in yt? It seems strange to me that the axes and ‘radius’ fields are correct but not the other geometrical components. 

Thanks again for your help!

Antoine


> 
> Best regards,
> 
> Antoine
> 
> 
> Le 2014-08-07 à 19:16 , Andrew Myers <atmyers2 at gmail.com> a écrit :
> 
>> Hi Antoine, 
>> 
>> Actually, on closer inspection I think you may have found a bug in the Chombo frontend. Thanks for bringing this to our attention. Would you mind checking whether these changes fix the problem for you? 
>> 
>> Thanks,
>> Andrew 
>> 
>> 
>> On Thu, Aug 7, 2014 at 11:28 AM, Andrew Myers <atmyers2 at gmail.com> wrote:
>> Hi Antoine,
>> 
>> I'm having some trouble reproducing your issue. When I run the attached script on the TurbBoxLowRes dataset, I get the following png files, the last of which is different than yours. Could you tell us what version of yt you're running? 
>> 
>> Thanks,
>> Andrew Myers
>> 
>> 
>> On Thu, Aug 7, 2014 at 10:29 AM, Antoine Strugarek <strugarek at astro.umontreal.ca> wrote:
>> Hi Nathan,
>> 
>> Many thanks for the fast answer. I just tried to reproduce my problem with existing data (the ‘TurbBoxLowRes’ data from yt-project.org/data) and I get the same issue. 
>> 
>> I just attached at the end of this email the small script I use to generate my fields VRA, VRB and VVR, which is adapted to the TurbBoxLowRes case. I also tried your suggestions of not adding my derived field as type ‘chombo’, but it did not solve the problem. 
>> 
>> I also attached the same snapshots from the TurbBoxLowRes case, VVR should be the sum of the two other and as you can see the blue negative patch on the right should clearly not be there (the color scale is the same in all the plots). It does not seem overall far off so I guess this is really dumb on my side, thanks again for your help!
>> 
>> Antoine
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> Le 2014-08-07 à 13:07 , Nathan Goldbaum <nathan12343 at gmail.com> a écrit :
>> 
>>> Hi Antoine,
>>> 
>>> I'm not sure what's going wrong here.  I have a few ideas below.  If the dataset is small enough it would probably help if you could share it using e.g. dropbox or google drive along with your full analysis script. Alternately, can you reproduce the issue using one of the public datasets on yt-project.org/data?
>>> 
>>> 
>>> On Thu, Aug 7, 2014 at 9:10 AM, Antoine Strugarek <strugarek at astro.umontreal.ca> wrote:
>>> Hello,
>>> 
>>> I’m new to yt so this maybe solved easily, though it puzzled me for quite some time and I still don’t understand what is going on. 
>>> 
>>> I try to create derived fields to analyze a simulation using AMR, from an output from CHOMBO. I define the following derived fields: 
>>> 
>>> def _VRA(field,data):
>>>     return  data['Cylsin']*data['Vx2']
>>> def _VRB(field,data):
>>>     return  data['Cylcos']*data['Vx1']
>>> def _VVR(field,data):
>>>     return  data['VRA']+data['VRB']
>>> 
>>> Are 'Cylsin' and 'Cylcos' on-disk fields or are they derived fields as well?  If so, can you share their definitions?
>>>  
>>> 
>>> Then I add them to my yt object:
>>> 
>>>     ds=yt.load(file)
>>>     ds.index
>>>     ds.add_field(('chombo','VRA'),function=_VRA,units='cm/s',take_log=False)
>>>     ds.add_field(('chombo','VRB'),function=_VRB,units='cm/s',take_log=False)
>>>     ds.add_field(('chombo','VVR'),function=_VVR,units='cm/s',take_log=False)
>>> 
>>> and everything goes on smoothly (they are the only variables named this way). Now, If I try to slice VRA and VRB I obtain the (correct) attached plots. Both VRA and VRB are strictly positive. If I try to slice VVR which is the sum VRA+VRB, I obtained the third attached plot which does not correspond to the expected sum (there are even negative values)! I suspect something went odd in the slice function, but I used the exact same lines of code to generate the three plots.
>>> 
>>> What happens if instead of passing in the field tuple ('chombo', 'VRA'), you instead pass in 'VRA' or ('gas', 'VRA').  Saying the field type is 'chombo' for a derived field doesn't really make much sense.  For a chombo dataset, a 'chombo' field must be on-disk and is always in code units.  By creating a derived field with explicit CGS units you might be confusing yt's field system.
>>> 
>>>  
>>> 
>>> I must be missing something here but I really don’t get it. Many thanks in advance for your help!
>>> 
>>> Antoine
>>> 
>>> 
>>> Antoine STRUGAREK
>>> -------------------------------------------------------------------
>>> Webpage 
>>> Département de physique, Université de Montréal
>>> strugarek at astro.umontreal.ca
>>> (+1) 514 343 7077
>>> --------------------------------------------------------------------
>>> DSM/IRFU/SAp/LDEE CEA Saclay
>>> DSM/IRFM/SCCP CEA Cadarache
>>> antoine.strugarek at cea.fr
>>> --------------------------------------------------------------------
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> yt-users mailing list
>>> yt-users at lists.spacepope.org
>>> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
>>> 
>>> 
>>> _______________________________________________
>>> yt-users mailing list
>>> yt-users at lists.spacepope.org
>>> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
>> 
>> 
>> _______________________________________________
>> yt-users mailing list
>> yt-users at lists.spacepope.org
>> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
>> 
>> 
>> 
>> _______________________________________________
>> yt-users mailing list
>> yt-users at lists.spacepope.org
>> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
> 
> 
> _______________________________________________
> yt-users mailing list
> yt-users at lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
> 
> 
> _______________________________________________
> yt-users mailing list
> yt-users at lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.spacepope.org/pipermail/yt-users-spacepope.org/attachments/20140808/9f68d12d/attachment.htm>


More information about the yt-users mailing list