Porting to SF

[parkjm]

Todo list to use SF version for previous workflows operated in SWIM version

• relax hard-coded name of "update_state" and its location

[parkjm]

@ORNL-Fusion/ips-support-team

IPS assumes that "update_state" executable located in framework bin directory. For a set of AToM workflows (core 1.5D, EPED, SOL tranpsport, ...), each workflow defines its own plasma state file and update_state needs to be different. We may just relax the hard-coded "update_state" as controllable name in the workflow configuration file?

[dlg0]

I think the location has already been generalized to be within the PATH env var in the latest IPS.

[dlg0]

Not that that really helps you at all. Just wanted to point it out.

[elwasif]

I think @dlg0 is referring to merge_plasma_state() which causes the framework to invoke a binary that is part of the PPPL PS build, hence it will need to know where to find it. The issue @parkjm raises has to do with which files make up the "Plasma State" for each component (I think).

There's no update_state executable. Calling update_state() merely copies the component's local set of plasma state files into the shared plasma state directory in the current simulation. This set of files is by default defined in simulation-wide configuration parameter PLASMA_STATE_FILES. However, each component can override this definition in its local config section, if it needs to only copy a subset of these files in and out. As far as the framework is concerned, these files can be anything (not necessarily THE PPPL PS file). So if different componnets read/write different files, then the union of this set of files is what constitutes the "global" plasma state files

[parkjm]

@elwasif

Well, no question on PLASMA_STATE_FILES, services.update_state(), overriding, ... well defined.

The problem I have is service.merge_current_plasma_state() that calls an executable named as "update_state", as coded

update_state = os.path.join(fwk_bin_path, 'update_state')
...
retval = subprocess.call([update_state, '-input', target_state_file,
                                  '-updates', partial_state_file],
                                  stdout = merge_stdout,
                                  stderr = subprocess.STDOUT,)

For example, I have two workflows, ips-fastran and ips-eped that use totally different PLASMA_STATE_FILES. So service.merge_current_plasma_state() has to call different "update_state" executbales for ips-fastran and ips-eped, respectively. We have to let IPS know which executable of "update_state" needs to be called, rather than hard-coded.

[elwasif]

@parkjm Well, this update_state was not envisioned to be component specific, and I'm not even sure it's what you want. This was meant for the case when you have two components, executing concurrently, making changes to separate parts of the PS file. The idea was that we want to merge their outputs into the common plasma state without overwriting the contribution from the other component. In the case where components execute sequentially, you simply need to make syure the plasma state has the outputs in there before you call update_plasma_state()

[parkjm]

@elwasif

This was meant for the case when you have two components, executing concurrently, making changes to separate parts of the PS file. The idea was that we want to merge their outputs into the common plasma state without overwriting the contribution from the other component

This is exactly what I want to have, for ips-eped, ips-solps, ips-c2, etc.

Yes, "update_state" should not be envisioned to be component specific. But right now, it is component specific that works only for tsc, fastran, nubeam, ... based on Princeton plasma state file.

I thought that a simple resolution might be replacing

update_state = os.path.join(fwk_bin_path, 'update_state')

by

update_state = conf["UPDATE_STATE"]

The idea is making merge_current_plasma_state() be generic as update_plasma_state() is.

[elwasif]

I think this can be done. The approach would be for the framework to check the existence of UPDATE_STATE in the component config section and use that if found, otherwise use the default one that comes with the PPPL PS (this way we don't break existing component wrappers)

[parkjm]

@elwasif Perfect, thanks!