Reverse Workflow Completed – OK to Open PR?

[sapiriscfdc]

I've finished implementing the reverse workflow and tested it on several SimpleFoam examples that Lion and Nir sent me. Everything appears to be working well.
Would it be okay to open a pull request and merge it into main?
Let me know how you'd like to proceed.

[yehudarav]

Sure. Thank you.

…

On Sun, Nov 23, 2025 at 7:47 PM Sapir ***@***.***> wrote: Assigned #160 <#160> to @yehudarav <https://github.com/yehudarav>. — Reply to this email directly, view it on GitHub <#160 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AMCON2JJ77DFIWIOJGKNHYD36HXJNAVCNFSM6AAAAACM6TZSU2VHI2DSMVQWIX3LMV45UABCJFZXG5LFIV3GK3TUJZXXI2LGNFRWC5DJN5XDWMRRGEZDGMZWGI3DQMA> . You are receiving this because you were assigned.Message ID: ***@***.***>

[sapiriscfdc]

Commit in 76c6a39 and push to master. Thank you!

[yehudarav]

Hi @sapiriscfdc

I see that you did a lot of good progress. I think there are still edges that need to be worked on (probably next year):

1. The reverse is working only on simpleFoam right now. It should be more general and the name of the solver can be taken from the controlDict/application

2. The names of the fields depend on the solver. we should have a mechanism that returns the names of the fields if we know the solver name, and I guess we will just fill it with time.

Some minor issues:

1. The reverse should be in the bin file and it should call functions in a CLI module
2. The version is the version of the workflow, not of the different nodes. Therefore it must be set once and accessed only
   once.
3. There is a major bug that breaks all our code right now - you assume for version 1 that the template name will be given in the node level. However, this was not part of the specification and now it breaks.

[yehudarav]

Few other things to notice:

1. We should not hard code directories into the code (see your version of the jinjaTemplate
2. we cant you '/' as path seperator because it will break in windows. The right way is using os.path.sep
3. Can you explain why we need to propmote the keys in the jinjaTemplate?
   why the standard template does not take care for it?

`
if isinstance(parameters, dict):
ctx.update(parameters)

        # Promote known nested keys to top-level in context
        nested_keys_to_promote = [
            "fields",
            "default",
            "values",
            "solverProperties",
            "relaxationFactors",
            "parameters"
        ]

        for key in nested_keys_to_promote:
            if key not in ctx:
                val = parameters.get(key)
                if isinstance(val, dict):
                    ctx[key] = val

    # Always fallback defaults for robustness
    ctx.setdefault("solverProperties", {})
    ctx.setdefault("fields", {})
    ctx.setdefault("default", {})
    ctx.setdefault("values", parameters if isinstance(parameters, dict) else {})
    ctx.setdefault("parameters", parameters)
    ctx.setdefault("input_parameters", parameters)

`

[yehudarav]

From what I remember, we said that there will be 1 general jinja that will just traverse over the tree and print key->value.

Why did you build a specific v2 termplate for each node? This is not a good solution, because we will now still need to keep track over all the different nodes, in all the different versions of openfoam.

[yehudarav]

For example, in fvSolution you have hard-coded the SIMPLE algorithm. However, even the old verion of fvSolution used algorithm.

The general translation back and forth will not care about these details.

[sapiriscfdc]

Hi, @yehudarav
Thank you for the detailed feedback and I apologize for the earlier misunderstanding regarding the v2 templates.
I’ve now pushed an updated version to branch Issue161, which uses a single, general Jinja template for reverse workflow. Most of the architectural and formatting issues you raised have been addressed.
Here’s a summary of what’s been done:

Completed Tasks:

• One General Template for Reverse Workflow.
Version 2 now uses a single generic Jinja template that dynamically renders the entire input dictionary. No more per-node templates in v2.

• Use workflow["version"] which set once in the full workflow object. Avoids per-node version checks.

• Fixed Template Detection in v1 (Major Bug).
JinjaTransform no longer assumes a template field per node. The template path is now inferred from the node’s type.

• Removed Solver-Specific Logic.

• Removed Hardcoded Paths.

• Removed Context Key Promotion.


• Reverse Functionality via CLI
Available using:


(Here’s an example from my local setup — you can replace the paths with your own)

python3 -m hermes.workflow.reverse \
/Users/sapiriscfdc/Costumers/Hermes/ReverseCases/simpleFoam/T3A \
--output /Users/sapiriscfdc/Costumers/Hermes/ReverseCases/simpleFoam/T3A/reverseWorkflow.json \
--save

In January, I’ll move this under bin/ and wrap it in a clean CLI interface.

Due to how PyFoam parses OpenFOAM files, there are some output format differences in the regenerated files:
1 on/off → True/False (Python-style booleans)
2 (1 2 3) → [1, 2, 3] (converted to Python lists)

It was important to me not to leave the reverse workflow in a half-working state, especially when it impact other parts of the system.
Let me know if you'd like me to go ahead and push this to master.

Sapir

[sapiriscfdc]

@yehudarav

[sapiriscfdc]

@lior-antonov