Gas Profile from hdf5

[f-schmitt]

This pull allows to load the gas profile from an hdf5 file.

Update: The Valgrind errors happen in mainline/dev too, see #267, thus unrelated to this change.

[f-schmitt]

Question: is there a way to access 3D-DataBox using a continuous 1D-index?
This would be helpful here.

[f-schmitt]

Question: When I try to pass the device DataBox directly here, I get a pure virtual function call error but when I use an intermediate variable, it seems to work. Any ideas?

[psychocoderHPC]

Please highlight the line which you mean with here if I follow the link I can't see which line you mean.
3D DataBox can't access as C array but you can use DataBoxDim1Access were you can access with operator[] I think this is what you need. Is it?

[f-schmitt]

It's line 215 in Particles.tpp, which is the line you get top-most when following the link. I don't know why it isn't highlighted.

Yes, DataBoxDim1Access looks fine for me, thx.

[psychocoderHPC]

Please add in all GasProfiles where fieldTmp is not used only the type FieldBox without a variable name, else we get compiler warnings unused variable or similar.

[f-schmitt]

Alright, let's shoot at STUFF!

(scaled with gimp)

[ax3l]

Yeah, FRY!!!! 🚀

[psychocoderHPC]

Cool my nvidia logo idea is comming 👍

[ax3l]

First we shoot on a PIConGPU logo, then on everyones facial profile to see who gains the highest energies (thx @bussmann for that idea).

[f-schmitt]

Re-assigned @ax3l since @psychocoderHPC is still enjoying vacation (or so I hope).

[f-schmitt]

This currently only works for a single GPU. For multiple GPUs, the overlapping regions are not properly loaded (see below):

[ax3l]

An idea for improvement:
The hdf5 file right now defines a field that has to match exactly the number of cells in the sim.

Let us lower that burden a bit by setting a constant value in gasConfig.param -> namespace gasFromHdf5 for all cells that are not between the beginning and the end of the hdf5 dataset. That constant should also have a value between [0.0, 1.0] (default: 0.0 for vacuum).

This would allow target designers to design a narrow target somewhere in space that they can move by defining the total_offset of the input field (in experiment: moving the target in or out of focus).

[f-schmitt]

It seems the content is somewhat shifted after all...

[ax3l]

I think the next GPU just starts reading one supercell "too late".

[f-schmitt]

Apparently, not shifting the databox at all seems to work for multiple GPUs (tested for 1, 2 and 4), any explanation for this?

PMACC_AUTO(dataBox, fieldBuffer.getHostBuffer().getDataBox());
typedef DataBoxDim1Access< typename GridBuffer<Type, simDim >::DataBoxType > D1Box;

D1Box d1RAccess(dataBox, fieldNoGuards);

for (int i = 0; i < bufferSize; ++i)
   d1RAccess[i].x() = tmpBfr[i];

[ax3l]

you probably did not shift fieldTmp during filling from hdf5 and now corrected for that in the second call during Dim1Access?

[f-schmitt]

I don't understand what you mean by this. As my comment states, I did not shift anything. I obtain the host databox to fieldTmp (which is larger than the data in the HDF5 file), obtain 1D access to it with the size of the data in the HDF5 file and than just copy data from HDF5 to the databox directly. In my understanding, it would be required to shift the databox with guard-offset because otherwise, my 1D access would include guard data.

[ax3l]

What I mean: I think you should shift your Dim1Access again in Line 114 und put a according guard shift in the kernel before accessing fieldTmp(cellIdx).x() in line 168.

[f-schmitt]

This has been tested to work with moving window and 3 (y) GPUs. Targets can be smaller and larger than the actual simulation area and can start at any 3D offset. The rest of the simulation area is filled with a default value gasDefaultValue, currently 0.0.

[ax3l]

wow, great! ✨

[f-schmitt]

[psychocoderHPC]

👍 coooool

[ax3l]

Hrhr, you will be loved for that 😸

[ax3l]

One work-flow we probably still have to think about is: how to restart from our FieldTmp generated charge density. Since the values there are not scaled to [0:1] this could be a bit tricky.

We might need some post-processing or an other option to override the GAS_DENSITY_SI range in a clever way with a value from hdf5...
We might also rescale the values there using the min/max from #237 .

Anyway, does not have to go with this pull request - we can open a new issue for that :)

[PrometheusPi]

👍

[bussmann]

We need this for the GTC talk!!!!!!

On 13. März 2014 17:22:04 MEZ, f-schmitt-zih [email protected] wrote:

---

Reply to this email directly or view it on GitHub:
#261 (comment)

Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.

[f-schmitt]

Continued as #280, closed.