Hello,
We're looking for a way to visualize the horizons from AHF as snapshots in time, preferably in lockstep with data generated from CarpetIOHDF5.
We've been using VisIt to create plots and images of data generated by CarpetIOHDF5. We considered using the xdmf script mentioned in https://trac.einsteintoolkit.org/ticket/1828 but this seemed to trace out the apparent horizons over all time and did not appear suitable to creating a snapshot at a particular iteration.
Is there a known solution for this? Perhaps using CarpetIOHDF5 with some of the AHF variables to generate a some sort of region in VisIt corresponding to the apparent horizon?
Thanks, Michael Clark
On Mon, Nov 09, 2015 at 06:41:43PM +0000, Michael Clark wrote:
We're looking for a way to visualize the horizons from AHF as snapshots in time, preferably in lockstep with data generated from CarpetIOHDF5.
We've been using VisIt to create plots and images of data generated by CarpetIOHDF5. We considered using the xdmf script mentioned in https://trac.einsteintoolkit.org/ticket/1828 but this seemed to trace out the apparent horizons over all time and did not appear suitable to creating a snapshot at a particular iteration.
You can give it the filename of a CarperIOHDF5 file, and it will then only include time steps for which this file has data, and in case no AH is found for time steps present there, will insert a bogus AH (not visible) to make visit happy.
AH2xdmf.py --help should help.
Frank
On 09/11/15 19:50, Frank Loeffler wrote:
On Mon, Nov 09, 2015 at 06:41:43PM +0000, Michael Clark wrote:
We're looking for a way to visualize the horizons from AHF as snapshots in time, preferably in lockstep with data generated from CarpetIOHDF5.
We've been using VisIt to create plots and images of data generated by CarpetIOHDF5. We considered using the xdmf script mentioned in https://trac.einsteintoolkit.org/ticket/1828 but this seemed to trace out the apparent horizons over all time and did not appear suitable to creating a snapshot at a particular iteration.
You can give it the filename of a CarperIOHDF5 file, and it will then only include time steps for which this file has data, and in case no AH is found for time steps present there, will insert a bogus AH (not visible) to make visit happy.
AH2xdmf.py --help should help.
Hi,
a few weeks ago, I suggested the following procedure to accomplish exactly what Michael is asking for:
http://lists.einsteintoolkit.org/pipermail/users/2015-October/004582.html
Incidentally, Ian has started collecting all these recipes on the ET wiki:
https://docs.einsteintoolkit.org/et-docs/Visualization_recipes
Please consider contributing something!
Eloisa
Hi Frank,
You can give it the filename of a CarperIOHDF5 file, and it will then
only include time steps for which this file has data, and in case no AH is found for time steps present there, will insert a bogus AH (not visible) to make visit happy.
AH2xdmf.py --help should help.
Frank
Yes, I have been using a CarpetIOHDF5 file in this manner, but what I get when I load the xdmf data and the h5 data into visit is not what I'd hoped: if I plot the hdf5 variable (say as a contour plot) alongside the horizon data (which is not clear to me how best to do this; I have tried using Subset as well as Mesh plots on the quantity "AHs"), I see the h5 data variable varying with the time slider, but the horizon plotted does not change with time. This is what led me to believe I was seeing the sum total of the horizon traced out over time, not an instantaneous snapshot at the same timestep as the h5 data variable.
Is this what I *should* be seeing? Should I be using some other plot type, or plotting some other variable from the xdmf?
If I load only the xdmf by itself, I don't get a working timeslider at all. Is this the behavior I should be seeing?
Is any of this behavior possibly influenced by Visit version, or version of its xdmf reader?
To Eloisa,
Hi,
a few weeks ago, I suggested the following procedure to accomplish
exactly what Michael is asking for:
Right now I'm still hoping to get the xdmf method working because it sounds like it might be more direct for making movies, but this is something I'm interested in if that method seems unworkable.
-Michael
users@lists.einsteintoolkit.org