Open eldond opened 1 year ago
There might be more to this one than simple boundary conditions. SOLPS can have other sources specified. Anyway, the point is to make sure IMAS describes particle sources that are in SOLPS. The control design workflow needs to know what actuators are doing.
Furthermore, maybe this should go the other way. That is, some other file might have to specify what an actuator is doing, then that is translated into SOLPS settings. Instead of reading SOLPS settings to know the actuator behavior, read the actuator specification from its own file.
This needs to be coordinated with ORNL team.
b2.boundary.parameters is a fortran namelist. There doesnt' seem to be a julia parser for fortran namelists available publicly. I found https://github.com/singularitti/Fortran90Namelists.jl , but it seems to be incomplete and stale. I couldn't use it. I want something like the OMFIT implementation that accepts a fortran namelist filename in and outputs a dictionary representing the contents. Furthermore, built on top of that is OMFITsolpsNamelist that does more to make sure files like b2.boundary.parameters get interpreted properly.
@eldond we have a namelist parser based on the singularitti
repository. I'll make it available with Apache 2.0 license shortly. For now you can access it at https://github.com/ProjectTorreyPines/Fortran90Namelists.jl .
SOLPS has boundary conditions in terms of density or particle fluxes at the mesh edges. We can try to turn these into gas flow rates and load them into IMAS. The ORNL team will have to turn gas flow commands into flow rates and then into SOLPS settings, so we should be able to invert the last step. There may be somewhere in edge_profiles for model constraints, and putting SOLPS BCs there would be fine, but regardless of whether that is done, I think it's best to put estimated gas flows into the dictionary for gas pipes/valves.