Skip to content

Conversation

@vidulejs
Copy link
Collaborator

The new preCICE schema will have additional options for fields, to specify solver_name and operation. This means that readData and writeData in preciceDict would be dictionaries instead of lists, so that these additional options can be parsed. For example:

  Interface1
  {
    mesh              Fluid-Mesh;
    patches           (interface);
    
    readData
    {
      Heat-Flux
      {
      	solver_name	T;
      	operation	gradient;
      };
    };
    
    writeData
    {
      Temperature
      {
      	solver_name	T;
      	operation	value;
      };	
    };
  };

I tried to look into ways to keep backwards compatibility with the lists, but this may not be desirable. The new schema warrants breaking changes. In order to read old config files, we'd have to check if it's a list or a dict. OpenFOAM does not make this easy... I tried to use the ITstream (Input Token Stream) to check whether the token is ( for list or { for dict. However the ITstream & dictionary.lookup(word &keyword) works only if i'm looking up a list and not a dict. I would need to write a custom parser. Similar issue on cfd-online forums.

TODO list:

  • I updated the documentation in docs/
  • I added a changelog entry in changelog-entries/ (create directory if missing)

…ionary AND list (for backwards compatibility).
@MakisH
Copy link
Member

MakisH commented Mar 20, 2025

For the review, I think we would need also a corresponding draft PR in the tutorials, porting at least one case (e.g., the flow-over-heated-plate).

@MakisH
Copy link
Member

MakisH commented Aug 1, 2025

Based on the latest state (list of dictionaries), it looks like we need a different, solution as described in precice/preeco-orga#38 (comment)

@MakisH
Copy link
Member

MakisH commented Jan 9, 2026

As operation, we could distinguish between gradient and normal-gradient (writing to be checked for consistency), to account for #380

@MakisH
Copy link
Member

MakisH commented Jan 9, 2026

To release it with v1.4.0, we need to implement it in a backwards-compatible way.

@MakisH MakisH added this to the v1.4.0 milestone Jan 9, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants