Open fusionby2030 opened 2 months ago
Hi Adam. Thanks for this, it's really great and very much appreciated!
Quickly looking through it, the approach looks very good and no problem to depend on the eqdsk and contour_generator libraries, due to their permissive licenses.
Thankfully, there is no need to port any of this code to JAX since all geometry processing is done in the initialization phase. You can take a look e.g. at https://github.com/google-deepmind/torax/blob/dbde9b46829939cd37399aa7d2a43e13f326a32f/torax/geometry.py#L832 , which is one of the class methods for generating the geometry structures based on a specific backend (FBT in this case).
What would be needed for EQDSK, is to populate the StandardGeometryIntermediates class using a similar constructor method, and then propagate some of the logic elsewhere in TORAX, e.g. add the extra EQDSK option to the various geometry_provider methods in build_sim.py
, reusing the existing patterns.
We'd be happy to accept a PR along these lines, and can actively help/co-develop if you prefer. Can also discuss over video call.
Regarding the comparisons, it's already looking very good. I'm wondering though if there is an explanation for some of the systematic differences, e.g. for <1/R^2>, Rout, Rin.
Ultimately it would also be good to have an integration benchmark against another integrated modelling tool using the same input EQDSK file, with same simple sources, transport, and boundary conditions.
Ultimately it would also be good to have an integration benchmark against another integrated modelling tool using the same input EQDSK file, with same simple sources, transport, and boundary conditions.
Regarding this, @jcitrin is there an EQDSK version of the CHEASE file used in the iterhybrid example? If so, then I can set up a side-by-side of that scenario in JETTO.
I've been testing out running TORAX from a JETTO config here https://github.com/theo-brown/jetto2torax.
There isn't an EQDSK version yet, but looking at the CHEASE repository, there seems to be functionality for outputing EQDSK files. It might be possible for CHEASE to run based on a CHEASE output file (or at least figure out which inputs are necessary from that output file to rerun), and then output an EQDSK. The original CHEASE file is in the PINT repository: https://gitlab.com/qualikiz-group/pyntegrated_model/-/tree/main/geo?ref_type=heads
Is this something you'd like to take a look at?
I've been testing out running TORAX from a JETTO config here https://github.com/theo-brown/jetto2torax.
Thanks, that's really useful.
It might be possible for CHEASE to run based on a CHEASE output file (or at least figure out which inputs are necessary from that output file to rerun), and then output an EQDSK
I'll have a look at this tomorrow!
Bit of an obstacle - it's very easy when you have the full .mat chease structure, as it actually saves the eqdsk within it. However, the one in the PINT repo is missing all but the chease-y bits. I've messaged Olivier Sauter about this, and whether there's an automated way of reconstructing the eqdsk. Failing that, we might be able to get the eqdsk of the same ITER simulation.
Great, thanks for looking into this.
Relevant PR for changes and issues uncovered when using the ITER EQDSK: #482
TORAX has a lot of potential and I have been excited to use it. However, I believe an outstanding issue is the lack of generalized geometry support. To this end, I would like to help add EQDSK support. Many EQDSK reading and writing tools exist already (most derived from Ben Dudson, c.f. TSVV-15's or freegs), which are able to handle the COCOS transformations given an g/f/-EQDSK file. The main trick is taking equilibrium from EQDSK and calculating the flux surface averaged quantities. To this end, I append the following code which does this and compare it to a CHEASE run.
I have compared the above transformation with that from CHEASE when ran with the same equilibrium.
I expect that with modifications (e.g., porting to JAX) this could be implemented relatively easily into the
geometry.py
, but I expect it would take much less time for the TORAX team to implement than it would for me to do this, which is why I only supply the above code to help inspire and start the discussion. I attach the following files to reproduce this above (both have filenames that end in .txt which is the only supported version filetype to upload):eqdsk_cocos02.eqdsk
, the G-EQDSK file used above (arbitrary tokamak) eqdsk_cocos02.eqdsk.txtchease.cols
, the CHEASE file used in comparison chease.cols.txt