pythonic input templator

[hightower8083]

Hi all c++ pure-bloods,

For those who are interested, here is a draft of a Mako-based input generator. https://github.com/hightower8083/PoGit The purpose is to provide a simple pythonic interface to PIConGPU simulation construction -- somewhat in the spirit of upcoming PICME standard.

It's of course very raw, not really elegant, and for now covers only a basic functions - simulation grid, species and lasers. Density and laser profiles still need to be added with basic code pieces, but I think this can be expanded relatively flexibly. It's also pretty handy to use it as a start, and then add tricky parts manually.

[ax3l]

What is this witchcraft, I love it! :smiley:

Don't forget we have some wrappers already in place from @codingS3b to play with tbg and .cfg files as well:

• lib/python/picongpu/input/
• examples/LaserWakefield/lib/python/picongpu/params.py

but instead of using our usual C-macro + cmakeFlags trick for .param files writing via more expressive python macro languages (Mako or jinja) is a good idea!

@n01r @codingS3b @PrometheusPi @berceanu you Python heroes want to see this magic!

[hightower8083]

templating templates of the templates :-D

have not seen this module — its cool, but still close to the code. My idea is to isolate users from knowing too much of the source. Biggest pain are species which produce many code-pieces in different files, and pieces are sometimes comma-separatrd and sometimes not )) for that two-level templating is a good solution

i heard of jinja, but got more used to Mako, when templated arbitrary mode-number kernels for a circ code.

by the way, quick question — for the standard ions, is it easy to retrieve MassRatio and ChargeRatio from tables and avoid passings these arguments to the speciesDefinition?

[n01r]

Yeah, it would be possible to build a table for them. We basically have the tables for the atomic numbers of the elements which contain proton and neutron number. The sum of these two multiplied by the atomic mass unit and divided by the electron mass gives your the mass ratio. For the charge ratio it is the same. But one should still be able to also manipulate them in order to build arbitrary species.

[hightower8083]

Yes, after some thinking I agree that its probably better to avoid implicit definitions, and keep the flexibility.

So I'll keep charge and mass ratios is the Particle class, but I think its should be mainly used for the generic_nonionizable type (to be added), otherwise one messes up with the nature of elements =)

[ax3l]

for the standard ions, is it easy to retrieve MassRatio and ChargeRatio from tables and avoid passings these arguments to the speciesDefinition?

You can also fully change the reference mass and charge in speciesConstants.param. That way, you don't need to specify charge and mass of multiple of an electron in speciesDefinition.param. That said, I would just keep it m_e and q_e and use scipy constants? Such a table is probably something we can pull easier in Python than adding it to the C++ files, and then we just add the numeric value during templating?

[hightower8083]

@ax3l totally agreed -- should be taking maximum advantage of python functionality. mendeleev (or periodic) provides a full deck of these numbers -- i'll add it

[ax3l]

In coordination with @codingS3b, we could also think about mainlining this functionality in the future, so we can integrate it in CI for syntactic changes of our input that influence the templating.

Also, allows us to write a central documentation on how to use it :)

[hightower8083]

Yes that would be cool to do systematic check for compatibility!

Also this will probably get more contributions -- I'll not be able to cover much of the things that i'm not using myself (like some manipulators and plugins), and codelets library should be improved and extended.

Concerning the docs, it would be nice to get them online -- most of what's worth mentioning about the main classes is already documented on the user level, but there is still much to do.

I've spoken with Remi, and they also want to be in touch about it, as its so close to what they are looking for in PICMI. Such templating seems to be sufficiently flexible to be extended to most of PIC functionality, and being as versatile as it is, PIConGPU is a good playground for the standard designing. As soon as this module gets enough maturity it can be shaped and merged into PICMI as well (by that time u'll probably be there 🏄‍♂️)

So whenever you have time, take a good look, and i'll be happy to process any suggestions 🤓

[BrianMarre]

@psychocoderHPC is this covered by PICMI/PyPIConGPU?

[chillenzer]

I was also surprised to find it mentioned here. Given that it is stale for 4 years now, should PoGit be removed from the docs, @psychocoderHPC?

[hightower8083]

The tool did serve us greatly a few years back by making setups and simulation scans accessible for users without programming background. With a proper PICMI interface available, it is indeed a part of the history now, so feel free to remove its mentions from active doc-pages and close this issue.

[BrianMarre]

@PrometheusPi please also close the issue ;)