Hi, did anyone have a look at how to read Carpet 3D HDF5 data into the yt visualization software? In case you don't know it, it's a public-available python based visualization software: http://yt-project.org/
I recently saw a movie done with yt with volume rendering using data from an Athena simulations done by a PhD student here at JILA (the quality looked similar to Amira to me). He told me that one of the yt developers (Sam Skillman) is always interested to support other data formats, but before contacting him I wanted to check if anybody else had a look into it.
Cheers, Bruno
Dr. Bruno Giacomazzo JILA - University of Colorado 440 UCB Boulder, CO 80309 USA
Tel. : +1 303-492-0389 Fax : +1 303-492-5235 email : bruno.giacomazzo@jila.colorado.edu web: http://www.brunogiacomazzo.org
---------------------------------------------------------------------- There are only 10 types of people in the world: Those who understand binary, and those who don't ----------------------------------------------------------------------
On 9 Mar 2012, at 21:03, Bruno Giacomazzo wrote:
Hi, did anyone have a look at how to read Carpet 3D HDF5 data into the yt visualization software? In case you don't know it, it's a public-available python based visualization software: http://yt-project.org/
I recently saw a movie done with yt with volume rendering using data from an Athena simulations done by a PhD student here at JILA (the quality looked similar to Amira to me). He told me that one of the yt developers (Sam Skillman) is always interested to support other data formats, but before contacting him I wanted to check if anybody else had a look into it.
One possible route would be for CarpetIOHDF5 to output in the xdmf format. Do you know if yt supports this format? The idea is to write an XML file alongside the HDF5 file which describes the schema of the metadata file for visualisation purposes. This should be much easier than writing and maintaining a plugin for Carpet for every visualisation package.
We have a ticket open about supporting this in Carpet:
https://trac.einsteintoolkit.org/ticket/580
but we don't currently have the ability to write such a file.
Cheers, Bruno
Dr. Bruno Giacomazzo JILA - University of Colorado 440 UCB Boulder, CO 80309 USA
Tel. : +1 303-492-0389 Fax : +1 303-492-5235 email : bruno.giacomazzo@jila.colorado.edu web: http://www.brunogiacomazzo.org
There are only 10 types of people in the world: Those who understand binary, and those who don't
Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
Hi Ian, thanks for the info. I don't know if that format is supported, but I will ask.
Thanks, Bruno
On Mar 12, 2012, at 7:17 AM, Ian Hinder wrote:
On 9 Mar 2012, at 21:03, Bruno Giacomazzo wrote:
Hi, did anyone have a look at how to read Carpet 3D HDF5 data into the yt visualization software? In case you don't know it, it's a public-available python based visualization software: http://yt-project.org/
I recently saw a movie done with yt with volume rendering using data from an Athena simulations done by a PhD student here at JILA (the quality looked similar to Amira to me). He told me that one of the yt developers (Sam Skillman) is always interested to support other data formats, but before contacting him I wanted to check if anybody else had a look into it.
One possible route would be for CarpetIOHDF5 to output in the xdmf format. Do you know if yt supports this format? The idea is to write an XML file alongside the HDF5 file which describes the schema of the metadata file for visualisation purposes. This should be much easier than writing and maintaining a plugin for Carpet for every visualisation package.
We have a ticket open about supporting this in Carpet:
https://trac.einsteintoolkit.org/ticket/580
but we don't currently have the ability to write such a file.
Cheers, Bruno
Dr. Bruno Giacomazzo JILA - University of Colorado 440 UCB Boulder, CO 80309 USA
Tel. : +1 303-492-0389 Fax : +1 303-492-5235 email : bruno.giacomazzo@jila.colorado.edu web: http://www.brunogiacomazzo.org
There are only 10 types of people in the world: Those who understand binary, and those who don't
Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
-- Ian Hinder http://numrel.aei.mpg.de/people/hinder
Dr. Bruno Giacomazzo JILA - University of Colorado 440 UCB Boulder, CO 80309 USA
Tel. : +1 303-492-0389 Fax : +1 303-492-5235 email : bruno.giacomazzo@jila.colorado.edu web: http://www.brunogiacomazzo.org
---------------------------------------------------------------------- There are only 10 types of people in the world: Those who understand binary, and those who don't ----------------------------------------------------------------------
Hello Ian, Bruno,
thanks for the info. I don't know if that format is supported, but I will ask.
To my knowledge (I wrote an xdmf xml generator for SpEC so had reason to look into the specifications and source code), XDMF does not directly support AMR meshes I believe. It does support subgrids, but not grids where the fine grid overlaps the coarse one. At last there is nothing in the file format that would allow you to specify something akin to refinement levels or which region to prefer.
Yours, Roland
On 12 Mar 2012, at 17:01, Roland Haas wrote:
Hello Ian, Bruno,
thanks for the info. I don't know if that format is supported, but I will ask.
To my knowledge (I wrote an xdmf xml generator for SpEC so had reason to look into the specifications and source code), XDMF does not directly support AMR meshes I believe. It does support subgrids, but not grids where the fine grid overlaps the coarse one. At last there is nothing in the file format that would allow you to specify something akin to refinement levels or which region to prefer.
Right - when I first looked at it, this seemed to be the case. But I think I looked at it more recently and it had developed somewhat. Is that true?
On 12 Mar 2012, at 17:06, Ian Hinder wrote:
On 12 Mar 2012, at 17:01, Roland Haas wrote:
Hello Ian, Bruno,
thanks for the info. I don't know if that format is supported, but I will ask.
To my knowledge (I wrote an xdmf xml generator for SpEC so had reason to look into the specifications and source code), XDMF does not directly support AMR meshes I believe. It does support subgrids, but not grids where the fine grid overlaps the coarse one. At last there is nothing in the file format that would allow you to specify something akin to refinement levels or which region to prefer.
Right - when I first looked at it, this seemed to be the case. But I think I looked at it more recently and it had developed somewhat. Is that true?
It looks like you can have trees of "dataitems", so there is nesting information there. For example, you could have RL0 as a tree containing all the dataitems (i.e. uniform HDF5 datasets) from RL0, and then have RL1 as a subtree of this. The question is how this is supposed to be interpreted by the visualisation client. This paper
http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=4438005&tag=1
contains basically the same content as http://www.xdmf.org/index.php/XDMF_Model_and_Format, and they say that major work is done to support concepts such as AMR. So presumably the intent is that the current format supports AMR. My naive interpretation would be that within a tree structure, the parent items would logically contain the child items. The client could then either simply provide a GUI for switching on and off child items, and render both parent and child when both are "on", or it could be intelligent and clip the parent items to remove the portions which are overlayed with the child items. I remember Christian did some work in the VisIt plugin to make it aware of the containment relations between different Carpet datasets. The question is whether the XMDF readers interpret the data in the same way.
users@lists.einsteintoolkit.org
-
Bruno Giacomazzo -
Ian Hinder -
Roland Haas