I switched out proper_tea for the much more widely used package param. It supports much more than what my own library can do, though I personally think my version is more readable and easier to use.

Advantages of param:

• Better error reporting when setter conditions fail
• Has far more features than the ones I've used here
• Likely to be better supported in future

Disadvantages of param:

• Harder to read. I feel like positive_float(allow_zero=False) is easier to read than Number(1.0, bounds=(0, None), inclusive_bounds=(False, False)).
• Some parameters require a non-optional default value, such as the example above of a float greater than zero. It may not always be obvious what this should be, and you often have to repeat the default values given in your __init__ function.

@shimwell what would you think of adding to ops some plotting features by importing openmc_source_plotter?

I wonder if the packages should be merged. I guess the question is: "Would the openmc_source_plotter be used outside of fusion applications?" If the name of this org is fusion-energy, i think the answer's no. Maybe these two packages could be merged to reduce the number of dependencies.

What do you think?

@Shimwell what do you think of this?

I've implemented the method of this paper in this python code

What I didn't realise at first is that it's in fact what Andy did in parametric-plasma-source....

This PR is a rework of #63 with feedback taken onboard.

The source class is now openmc.Source and it has been monkey patched to add the desired plotting methods.

This now just looks and behaves like a regular openmc source but it has a few plot methods

Just running the tests on the main or develop branch and I am seeing this error and getting one failing test

    @given(tokamak_source=tokamak_source_strategy())
    @settings(max_examples=50)
    def test_strengths_are_normalised(tokamak_source):
        """Tests that the sum of the strengths attribute is equal to"""
>       assert pytest.approx(sum(tokamak_source.strengths)) == 1
E       assert nan ± ??? == 1
E         comparison failed
E         Obtained: 1
E         Expected: nan ± ???
E       Falsifying example: test_strengths_are_normalised(
E           tokamak_source=TokamakSource(angles=(0, 6.283185307179586), elongation=1.0, ion_density_centre=1.09e+20, ion_density_peaking_factor=1, ion_density_pedestal=1.09e+20, ion_density_separatrix=3e+19, ion_temperature_beta=6, ion_temperature_centre=45.9, ion_temperature_peaking_factor=8.06, ion_temperature_pedestal=6.09, ion_temperature_separatrix=0.1, major_radius=1.0, minor_radius=1.5258789062500003e-05, mode='H', name='TokamakSource', pedestal_radius=1.52587890625e-05, sample_size=1000, triangularity=0.0),
E       )

This update aims to bring openmc-plasma-source in line with PEP 517 recommendations for packaging etc. The build/install details in setup.py are moved to setup.cfg and pyproject.toml as simple input files. Rather than calling:

• python setup.py install/python setup.py develop
• python setup.py sdist bdist_wheel

One should instead call:

• pip install ./pip install -e . (for 'develop' mode)
• python -m build

Rather than using a requirements file, the project requirements may be listed in setup.cfg, and optional dependencies may be installed using:

• pip install -e .[tests] (-e is optional)

This update also introduces automatic version inference, meaning the git tag is the 'single source of truth' for versioning. The version is updated with developer tags when between patch versions, i.e. one commit after 0.5.3 will be 0.5.4.dev0+[git commit].d[date].

Not ready for review yet, missing tests

Adding a few more sources. This adds a simple ring source and a point source.

This point source is useful for inertial confinement fusion This ring source is useful for magnetic confinement fusion when extra plasma details are not known

TODO tests

I've made a series of updates to TokamakSource to ensure it can't be set up with broken data, and cleaned up some TODO sections while I was at it.

The most significant change is the introduction of a utility file called properties.py, which implements a somewhat-generic 'property factory' and a few specific use cases. This allows you to do things like declare a class attribute must be a positive float, and protects against setting it to something inappropriate after initialisation. It might be a little overkill for these purposes, and it can instead be achieved by a simple list of checks within TokamakSource.__init__. I've mocked up both methods, and will submit the other version as a separate pull request. It's worth noting that I'm working on developing the property factory bits into an independent package, so I may be able to remove these files in a later build and simply replace them with a new dependency in setup.cfg.

I believe I've figured out what combination of geometry inputs are acceptable (major radius, minor radius, pedestal radius, Shafranov factor, triangularity, elongation), but I don't know what bounds should be set on the various ion densities and ion temperatures. It would be helpful if you could let me know any further constraints we can place on these values.

There were some sections marked TODO within TokamakSource, in which a list of ion densities/temperatures was built one element at a time in a for loop: https://github.com/fusion-energy/openmc-plasma-source/blob/ddef660343a211d1e9498a2cdcf38961ee3bdefc/openmc_plasma_source/tokamak_source.py#L112-L130 These have been rewritten to make use of np.where. As NumPy is a little better for reporting floating point issues than raw Python, I'm now seeing RuntimeWarnings for 'invalid value encountered in power'. It's hard to say if there's actually a cause for concern here, as I don't believe I've changed the overall logic anywhere. It would definitely be worth looking over those changes in detail to ensure I haven't broken anything.

Finally, I've updated test_tokamak_source.py extensively, adding unit tests to ensure that TokamakSource builds correctly when fed 'good' data and that it exits in a particular way when fed 'bad' data. I also changed how the hypothesis strategy was working as it was struggling to generate useful data after a few more constraints were added.

I've added a test and refactored test_tokamak_source.py to ensure TokamakSource generates points within the expected shape. This change brings in hypothesis as an additional testing requirement, which is used to automatically generate a wide range of possible tokamaks and ensure it works for more than the single example given previously. It also includes a general refactor to avoid the repeated lines of code.

I believe this goes some way towards solving issue https://github.com/fusion-energy/openmc-plasma-source/issues/34, but I'd like to go a bit further. For example, the inputs to TokamakSource aren't checked for validity in its __init__ function. It would be quite straightforward to implement these checks and associated unit tests, and I could raise this as separate issue/pull request.

This PR adds some plotting features to the package.

The sources are now instances of openmc_source_plotter.SourceWithPlotting() which is just a class that inherits openmc.Source and adds some plotting methods.

The additional plotting methods are .plot_source_position, .plot_source_energy, .plot_source_direction and there is also a sampling method called sample_initial_particles

This doesn't remove any of the existing plotting methods but adds a few new ones.

Is there any chance I can change this line to allow versions above 3.3.4

https://github.com/fusion-energy/openmc-plasma-source/blob/e3931d18a9f53dcae23d158bbcd2e291ca3dab34/setup.cfg#L30

I am installing this package in some CI and getting this error

error: matplotlib 3.3.4 is installed but matplotlib>=3.4.3 is required by {'openmc-plasma-source'}

Looking at the earlier releases (pre .toml file) it looks like "matplotlib >= 3.2.2" was accepted

The sources should maybe have a method to compute the neutron rate in neutron/s .

usage could be

from openmc_plasma_source import FusionPointSource

my_source = FusionPointSource(.....)

neutron_rate = my_source.get_neutron_rate(fusion_power=1e9)  # for 1 GW

A github action can be added to check that proposed changes:

• Don't break the conda package building process
• That the built conda package passes the pytest tests

This action can perhaps be reused for this role.

I was looking at the functions in plotting and thought these should maybe be methods of TokamakSource so that users can do:

my_source = TokamakSouce(....)
my_source.plot_3d(...)

Currently just 'DD' or 'DT' sources are allowed using the fuel: str = "DT", argument

We could add sources that have a fraction of DT and a different fraction of DD with a more flexible input for fuel.

How about fuel also accepts a list of tuples, where the first entry is 'DD' or 'DT' and the second entry is the relative strength

fuel = [('DD', 0.1, ('DT',0.90)]

or is a dictionary better

fuel = {'DD':0.1, 'DT':0.9}

Not sure if this will work as we run ci in a container.

However it would be great if multiple python versions can be tested

Here is an example

https://github.com/C-bowman/inference-tools/blob/760061e77bdc8ddeacb951196a3deb783a6ccffd/.github/workflows/tests.yml#L16-L17