refactor: couple of issues in launch fluent

[mayankansys]

Context

Case/case-data files should be handled before journal files, and in lightweight mode journal reading should finish before sync starts.

Change Summary

This PR fixes the launch order in launch_fluent(). It makes sure case/case-data loading happens before journal processing, and in lightweight mode it delays sync until journal execution is complete.

Impact

This affects Fluent launch behavior when using case files, case-data files, journal files, and lightweight mode. Tests were added to cover these cases.

[codacy-production]

Up to standards ✅

🟢 Issues 0 issues

Results:
0 new issues

View in Codacy

_{NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.}

[mkundu1]

@mayankansys Is the following happening in the lightweight-mode?

bg session: read case + settings -> read journals -> make this as the main session -> apply changes that user made in the fg session
fg session: read settings -> start accepting changes from user -> shutdown after the main session is transferred

The journals should be read in the background session which reads the full mesh before it.

Additionally, I think the journals should be read in the foreground session also, because use will expect the journal is already read when they start making change in the activated foreground session. But I'm not sure if the journal has, e.g., a solve call, whether that will be a no-op when only settings are read.

[mayankansys]

@mayankansys Is the following happening in the lightweight-mode?

bg session: read case + settings -> read journals -> make this as the main session -> apply changes that user made in the fg session fg session: read settings -> start accepting changes from user -> shutdown after the main session is transferred

The journals should be read in the background session which reads the full mesh before it.

Additionally, I think the journals should be read in the foreground session also, because use will expect the journal is already read when they start making change in the activated foreground session. But I'm not sure if the journal has, e.g., a solve call, whether that will be a no-op when only settings are read.

Thanks @mkundu1 for the question and to make sure I understand before I rework on this:

The PR fixes the ordering but you're pointing at a separate problem which was, In lightweight mode the journals currently run on the foreground settings whihc doesn't have mesh.
I agree that's wrong for the mesh-dependent journals. A journal that calls the solve needs the mesh, so should I run on the background session that reads the full mesh matching the order which you described.

If the journal has solver call then I expect a solve in settings only session to either error or no-op which is more evidence the journals belong on the bg session. Kindly let me know what's you take on it.

One issue while implementation can be the bg session is inside read_case_lightweight() but journal reading currently happens in the launchers process_case_data_and_journals which has no handle to the bg session.
For doing this properly I think we need to move the journal reading into the lightweight read path.

Before I move forwards kindly let me know:

• Am I understading the thing properly and am I on the correct path ?
• Should Journals run only on the bg session or is there a case where they also need to run in the fg session ?

[mkundu1]

@mayankansys For the case/data+journal combination we can pass the case file name via the -case command line flag of Fluent (there is also -data command line flag for data files), Fluent will figure out how to read the case/data+journal combination and we can avoid any client-side logic/assumptions.

You can start Fluent with -help command line flag to see all supported command line flags.

[mkundu1]

@mayankansys For the case/data+journal combination we can pass the case file name via the -case command line flag of Fluent (there is also -data command line flag for data files), Fluent will figure out how to read the case/data+journal combination and we can avoid any client-side logic/assumptions.

You can start Fluent with -help command line flag to see all supported command line flags.

Was this considered? My primary intention is to avoid any client-side duplication of logic for the read-sequence.

We can use the command-line flags all the time even if only case or only journal name is provided. We can get rid of all the defered_journal_read logic in the current PR.

[mkundu1]

Launch argument			Implementation
case/data	journals(s)	lightweight_mode
FALSE	FALSE	FALSE	No-op
FALSE	FALSE	TRUE	Warn and ignore lightweight_mode, then no-op
FALSE	TRUE	FALSE	Pass -i to Fluent
FALSE	TRUE	TRUE	Warn and ignore lightweight_mode, then pass -i to Fluent
TRUE	FALSE	FALSE	Pass -case/-data to Fluent
TRUE	FALSE	TRUE	Keep current implementation with fg/bg sessions
TRUE	TRUE	FALSE	Pass -case/-data and -i to Fluent
TRUE	TRUE	TRUE	Warn and ignore lightweight_mode, then pass -case/-data and -i to Fluent

Above is the implementation plan in my mind.

[seanpearsonuk]

Similar to the earlier conversations on this method (see below), this continues a pattern I've flagged before: accumulation of low-level, untested branching logic. I understand this follows the existing style of the method, but each addition makes the eventual refactor larger and the method harder to review as a whole.

I'd like to see argument-validation branches like this (and the timeout-string construction from before) extracted into small, testable methods rather than added inline. Given this has come up multiple times now, including in internal meetings, please treat this as a standing convention going forward, not a case-by-case judgment call.

Final changes to the same method in same PR:

[seanpearsonuk]

As per my comment.