The hook for load() is in your StaticOutput class's _is_valid() method.  Take a look at the definition of the load function, in yt/convenience.py.<div><br></div><div>Also keep in mind that load isn't strictly necessary, it's just there for syntactic sugar.<span></span><br>
<br>On Saturday, August 24, 2013, Stuart Mumford  wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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><br><br><div>On 24 August 2013 08:50, Kacper Kowalik <span dir="ltr"><<a>xarthisius.kk@gmail.com</a>></span> wrote:<br>


<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>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><div><br>
><br>
> Stuart<br>
><br>
><br>
> On 24 August 2013 06:51, Nathan Goldbaum <<a>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 pro</div></div></blockquote></div></div></blockquote></div>