Workflow problem with parallel

[nicoroussouly]

Hello,

I'm working at IRT with gemseo.

I have two examples here that give a problem when generating the html file:

• With xdsm_parallel_of_parallel.json, we try to generate a workflow which contains a parallel bloc including itself two parallel blocs. In that case the html file cannot be seen, it seems that XDSMjs cannot interpret the parallel of parallel case, is that right ? Do you think it would be possible to add a new feature for this, or can you advice something to treat this case ?

• With xdsm_parallel_then_sequential.json, we have a workflow with three parallel disciplines sequentially chained with a single one. In that case, the workflow line is correctly distributed over the parallelized disciplines but not with the last one. We would like to see the workflow going from the 3 parallel disciplines to the last single one. Do you think it would be possible to fix that problem ?

Do not hesitate if something is not clear or if something is wrong in my data.

Thanks in advance.

xdsm_cases.zip

[relf]

Hi.

You certainly hit limitations of workflow handling. I am not sure about the first case (maybe a drawing will help here to understand the chaining). Regarding the second case, I remember that the idea was that a component controls somehow the parallel components like it synchronizes the parallel runs at the start and at the end. So I would say it is not surprising it does not work as you want.

The current implementation has clearly shortcomings. We end up parsing a json structure into some segments to draw and it should require a more involved implementation to handle all possible combinations. The current workflow "formalism" doe not seems to cover your needs.

XDSMjs tried to be smart for handling the workflow (chaining and numbering), but I doubt it can handle all GEMSEO possible nested workflows without somehow emulating GEMSEO handling. I think such handling would go beyond the initial scope of the library which is much more close to pyXDSM, that is a simple graphic library. It should better parse basic user directives to enable any workflow drawing/numbering which is not exactly the case currently.

[nicoroussouly]

Hi,
Ok thanks for your answer, I understand the matter.
Here is an illustration for the first case where the red line is what we would like to see:

For the second case, indeed we could add an additional component to control the workflow, which is done for some structure such as the MDAChain but not for the MDOChain neither for the MDOParallelChain. We are going to investigate this.

[relf]

Yeah, the current implementation definitely falls short to handle such nested parallel case. Not only you would like the red arrows but following the principle I stated above for parallel the MDAJacobis should have also fed back to AnalyticDiscipline.