<div dir="ltr"><div><div><div><div>Cool,<br><br>So how can I get the filename?<br><br></div>Ok so more generally what is the pipeline for reading a file that I need to replicate?<br><br></div><div>how to go from<br></div>>>>load('myfile')<br>

...<br>...<br>...<br><br></div>to returning a subclass of StaticOutput?<br><br></div>Stuart<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On 24 August 2013 08:50, Kacper Kowalik <span dir="ltr"><<a href="mailto:xarthisius.kk@gmail.com" target="_blank">xarthisius.kk@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="im">On 24.08.2013 09:46, Stuart Mumford wrote:<br>
> Hello,<br>
><br>
> Just a quick question that jumps out at me, it is possible to not use yt's<br>
> own hdf5 opening code and do it all in the frontend because I have a<br>
> library that abstracts the two data formats we have for the simulations,<br>
> only one is hdf5.<br>
<br>
</div>Hi Stuart,<br>
I doesn't matter what you use to get data from disk to memory in<br>
your_frontend/io.py as long as you get the job done ;)<br>
Cheers,<br>
Kacper<br>
<div class="HOEnZb"><div class="h5"><br>
><br>
> Stuart<br>
><br>
><br>
> On 24 August 2013 06:51, Nathan Goldbaum <<a href="mailto:nathan12343@gmail.com">nathan12343@gmail.com</a>> wrote:<br>
><br>
>> Hey Stewart,<br>
>><br>
>> Take a look at the FLASH frontend, specifically<br>
>> yt/frontends/flash/data_structures.py.<br>
>><br>
>> In FLASH, the IO is handled by relying on h5py.  If you look at the<br>
>> beginning of FLASHStaticOutput.__init__, you'll see that a _handle<br>
>> attribute is assigned to the instance. This _handle is a reference to the<br>
>> open h5py File object.  Optionally, FLASH allows a particle file which is<br>
>> written to disk seperately from the main hydro data file, so that is<br>
>> optionally opened as well and the File handle is assigned to<br>
>> _particle_handle.<br>
>><br>
>> FLASHStaticOutput._handle is then used many times elsewhere to read data<br>
>> from the output file and to create an in-memory view of the FLASH AMR data<br>
>> structure.  The AMR hierarchy is handled by FLASHHierarchy, and data IO is<br>
>> also logically handled there, although via a FLASHIOHandler instance.  The<br>
>> IOHandler is defined using a bit of metaclass magic via the io_registry,<br>
>> which is set up in the IOHandler base class in yt/utilities/io_handler.py.<br>
>>  If you look in yt/frontends/flash/io.py, you'll find the definition for<br>
>> FLASHIOHandler, which implements all the IO for hydro data.  Since it uses<br>
>> h5py, this all happens via a dict-like interface.<br>
>><br>
>> I'm not sure if there is an exhaustive list of things that a StaticOutput<br>
>> object needs to implement.  There is probably a minimal number of<br>
>> parameters that the rest of the code needs to know about and that list of<br>
>> things should probably be written down somewhere.  I would look at a few of<br>
>> the frontends (FLASH and Orion are simple, relatively clean examples; the<br>
>> enzo frontend is unfortunately a bit messy, there's been a lot of work<br>
>> recently on the Ramses, SPH, ART, and ARTIO frontends) and try to implement<br>
>> functionality that is common between the codes.  A couple examples spring<br>
>> to mind.  All StaticOutput sublcasses need to define a parameters dict and<br>
>> a minimal set of parameters needed elsewhere.  Similarly, there needs to be<br>
>> a units dict which defines unit conversions.<br>
>><br>
>> Frontends also define a fields.py file.  Right now, frontends needs to<br>
>> implement fields with enzo field names (so, 'Density', 'Pressure',<br>
>> 'x-velocity', 'GasEnergy', 'TotalEnergy', etc.) because universal_fields.py<br>
>> assumes these field names are defined and in CGS units.  There's an effort<br>
>> to make this situation better, both by providing an updated list of field<br>
>> names, and a unit system, but that's currently on the backburner while Matt<br>
>> pushes ahead on necessary yt-3.0 infrastructure work.<br>
>><br>
>> You should also supply on-disk fields without conversions to CGS and with<br>
>> native field names - this is how we distinguish between 'yt' fields, which<br>
>> always have units and enzo field names, and on-disk fields, which are<br>
>> always in code units. As a curious aside, this ad hoc system is broken for<br>
>> enzo, making it a little non-trivial to access on-disk enzo data.  Like I<br>
>> said, the units refactor will make this better :)<br>
>><br>
>> I'll let Matt explain the distinction between known fields and unknown<br>
>> fields... ;)<br>
>><br>
>> Anyway, like Matt said on IRC, please let us know about sticking points in<br>
>> this process.  We really should have better documentation for how to write<br>
>> a frontend and it would be cool if we could streamline the process or<br>
>> simplify by refactoring and cleaning up the frontend code.<br>
>><br>
>> HTH,<br>
>><br>
>> -Nathan<br>
>><br>
>><br>
>> On Fri, Aug 23, 2013 at 4:37 PM, Stuart Mumford <<a href="mailto:stuart@mumford.me.uk">stuart@mumford.me.uk</a>>wrote:<br>
>><br>
>>> Hello,<br>
>>><br>
>>> First an introduction, I am Stuart Mumford I am doing a solar physics PhD<br>
>>> at Sheffield University in the UK. I work primarily on MHD wave simulations<br>
>>> of the solar atmosphere studying energy propagation and wave excitation.<br>
>>> The code SAC (<a href="http://www.aanda.org/10.1051/0004-6361:200809800" target="_blank">http://www.aanda.org/10.1051/0004-6361:200809800</a>) solves<br>
>>> for perturbations ontop of a fixed background to deal with the very wide<br>
>>> range of the parameters e.g. density and temperature in the solar<br>
>>> atmosphere. I also attended SciPy this year, where I met some of you and<br>
>>> discovered yt, mainly as a consequence of my contributions to SunPy (<br>
>>> <a href="http://www.sunpy.org" target="_blank">www.sunpy.org</a>) which is a solar physics data analysis library.<br>
>>><br>
>>> So that's that over with, now having been playing with yt on and off<br>
>>> since SciPy I started using it properly this week, as the need arose. I am<br>
>>> very impressed with yt's capabilities and I want to be able to make better<br>
>>> use of it. To that end I am trying to write a frontend for SAC, as I have<br>
>>> been speaking to some of you about in IRC (I am Cadair in IRC and on GH).<br>
>>><br>
>>> I have some questions regarding this, as far as I can ascertain a<br>
>>> frontend provides a mapper between the stored data and a abstracted format<br>
>>> that yt understands? I have started looking in the code for FLASH and<br>
>>> Stream to try and get an idea where to start and not got very far. So some<br>
>>> questions to start:<br>
>>><br>
>>> Where should the file handling be done?<br>
>>> Where is the file opened?<br>
>>> What things should the StaticOutput subclass define?<br>
>>><br>
>>> Thanks once again for your help on IRC over the last few days and I hope<br>
>>> you can point me in the right direction.<br>
>>><br>
>>> Stuart<br>
>>><br>
>>> _______________________________________________<br>
>>> yt-dev mailing list<br>
>>> <a href="mailto:yt-dev@lists.spacepope.org">yt-dev@lists.spacepope.org</a><br>
>>> <a href="http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org" target="_blank">http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org</a><br>
>>><br>
>>><br>
>><br>
>> _______________________________________________<br>
>> yt-dev mailing list<br>
>> <a href="mailto:yt-dev@lists.spacepope.org">yt-dev@lists.spacepope.org</a><br>
>> <a href="http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org" target="_blank">http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org</a><br>
>><br>
>><br>
><br>
><br>
><br>
> _______________________________________________<br>
> yt-dev mailing list<br>
> <a href="mailto:yt-dev@lists.spacepope.org">yt-dev@lists.spacepope.org</a><br>
> <a href="http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org" target="_blank">http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org</a><br>
><br>
<br>
<br>
</div></div><br>_______________________________________________<br>
yt-dev mailing list<br>
<a href="mailto:yt-dev@lists.spacepope.org">yt-dev@lists.spacepope.org</a><br>
<a href="http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org" target="_blank">http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org</a><br>
<br></blockquote></div><br></div>