Matej Tomes

I would go even further. Lets specify the format of the data the users have to provide to the parsing functions to get the problematic information in (e.g. wavelengths). Then...

Hi @vsnever , thanks for the feedback. At the beginning I thought that the beam would have only a single particle species needed for the models to work. You are...

Hi @vsnever , at the end, we will add the new architecture along the old one. The new one will be sitting in `particle_beams`. This was suggested by @jacklovell during...

Hi @mnurgaliev, I would like to expand the beam models in near future and adding the possibility to add the beam distributions from external sources is on the list. I...

I'm coming back to this issue, because it rose in other discussions. I think that to allow the external sources of beam properties, a rewrite of the beam architecture is...

It would be nice to hear opinion of @CnlPepper and @jacklovell about the `__future__` / `__past__` idea. I like the idea of users being able to adjust their codes with...

The new beam architecture will be added as `particle_beam` which will allow its existence alongside the currently used `beam` The deprecation warnings will be added to `beam` and it will...

Having beam foci inside plasma is something this model doesn't support and is it's limitation. I would personally wait with such changes for the new beam model which won't have...

Thanks for suggestions, I should not be allowed to come up with naming, because I like my names too descriptive. What about `CHERAB_OPENADAS_DATA`? @vsnever the suggestion `CHERAB_ATOMIC_DATA` should be kept...

@vsnever , I'm sorry I got confused between #364 and #377 ... I looked quickly into #377 and why would it be problem to name the environment variable `CHERAB_OPENADAS_DATA`? I...