Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Interfaces for laser-plasma codes #4

Open
valenpe7 opened this issue Feb 7, 2018 · 3 comments
Open

Interfaces for laser-plasma codes #4

valenpe7 opened this issue Feb 7, 2018 · 3 comments
Assignees

Comments

@valenpe7
Copy link
Owner

valenpe7 commented Feb 7, 2018

The laser_bcs library is supposed to be integrated with electromagnetic codes. To simplify the communication between the library functions with other codes, it is necessary to write some interfaces. Up to now, there is only one code supported (Epoch: https://cfsa-pmw.warwick.ac.uk/). Add more interfaces (e. g. Smilei, Warp, ...)

@valenpe7 valenpe7 self-assigned this Feb 7, 2018
@valenpe7 valenpe7 added this to the Release v2.0.0 milestone Feb 7, 2018
@ax3l
Copy link

ax3l commented Apr 3, 2018

Do you want tho add bindings to PIConGPU? ;-)

@valenpe7
Copy link
Owner Author

valenpe7 commented Apr 4, 2018

@ax3l Yes, I have it in my mind as well! :-) But first, I'd like to rewrite output routines (issue #13). Currently, the code uses MPI binary file, so one needs additional methods to retrieve the data. I haven't tried PIConGPU yet.. is there any easy way how to initialize a custom laser from file?

@ax3l
Copy link

ax3l commented Apr 5, 2018

File dumping (yay, you want to use openPMD as well) is a good idea for development. Have you seen openPMD-api yet? For code coupling, dumping the whole field is ok-ish but can be very storage and I/O intensive at scale. Just keep this in mind, parallel HDF5 does not perform too well at scale and you might want to consider in-transit ("staged") methods later on (also very much possible with openPMD).

In PIConGPU we currently initialize laser profiles two-and-a-half ways.
The default one "laser.param" initializes the em-field from a border or plane directly. An other way is to use the "fieldBackground.param" to define functions E(x,y,z,t) and B(x,y,z,t). In the same file one could also define a J(x,y,z,t) for a custom antenna.

If you want to hack on the boundary conditions there are two ways, the quick and the fast one. The quick way which would allow you to use your (host-side) C++ routines is just to synchronize the fields to the host (FieldE.synchronize()), manipulate the getHostDataBox() like any other C++ array and push it back (FieldE.syncToDevice()). This gives you quick results but is limited by the latency and bandwidth of PCI-E / nvlink.

The fast way: we write a kernel that updates the field directly on the device - probably also not too to change in your code as well :)

If you want to come around and visit our lab to work with us for a week or two just drop us a line, Prague and Dresden are really close :-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants