Refactor 4C random fields by gilrrei · Pull Request #176 · queens-py/queens

gilrrei · 2025-06-25T16:11:49Z

Description and Context:

This PR refactors 4C related stuff:

Remove ensight dataprocessor. 4C is switching to Vtu, and so are we. If you have EnSight files, use the pyvista dataprocessor.
The external geometry is removed. We used the numbering in the 4C input files to extract quantities in the output. This leads to nasty bugs as the numbering between input and output can change. Three possible solutions
1. Interpolate or sample (is like interpolation but uses mesh information) using pyvista at desired locations
2. Identify the node id in the 4C output and extract that entry using pyvista
3. Extract QoI with your custom script :)
A QUEENS interfaces package is introduced
A QUEENS example simulator functions package is introduced, it contains all our analytical benchmarking functions that can be used for testing and validating methods
To create random fields using 4C, we now require fourcipp as an optional dependency. To install it via QUEENS use pip install -e .[dev,fourc] (only needed if you want to work with random fields, not with 4C)
Random fields are no longer constructed by generating one or more materials per element; instead, the new from_file approach from 4C is used.
This PR deletes the approach to describe random boundary conditions. The code was brittle and tailored to specific cases. It didn't work for all cases, such that if you want to use RF for your BC you have to create your own code. (Support was dropped to the maintaining costs, and this would duplicate code from 4C itself)

I would appreciate some feedback on this before finishing the PR :)

Related Issues and Pull Requests

Closes
Related to

Interested Parties

Fix will follow in PR queens-py#176

leahaeusel

Just one thought upfront, without having read all the changes thoroughly:

leahaeusel · 2025-06-26T13:48:36Z

src/queens_interfaces/fourc/random_material_preprocessor.py

Is there a particular reason why you did not follow the

└── src/ ├── queens/ # contains QUEENS stuff ├── queens_4C/ # Contains all the 4C related stuff └── queens_XXX/ # Contains all the QUEENS stuff related to a project XXX

layout which you proposed in #174?

No particular reason, I was unsure what's better. That's why I asked for some feedback.

Honestly, I can live with both. What's your preference?

Maybe relevant for the decision process

First proposition

from queens_4C.some_module import SomeClass

Each project has its own subpackage

Redundant queens_

Second proposition

from queens_interfaces.fourc.some_module import SomeClass

Each project has its own subpackage, but is grouped with all other interfaces

no redundant name but is longer

I think I have slight preferences for the second option: From a modularity point of view the existence of queens_interfaces to me implies that I as a developer should be able to rely on a well-defined interface to the actual solvers when developing core queens code, while the existence of queens_4C or queens_fenics sub packages would not necessarily guarantee me this.. I mean, obviously in neither of the cases these assumptions need to be true, but that's why I prefer the second option from a psychological point of view --- not sure if this statement now made sense to anyone, but still 😄

And as for the drawback of being longer: It would still be possible to shorten it, e.g., if queens_interfaces.fourc would be needed more often inside the code, one could replace it through import queens_interfaces.fourc as queens_fourc or something similar. So I would vote option 2) but I also don't have a strong opinion :)

I have a slight preference towards the first layout because it reduces nestedness, but I'm also very much open to other arguments 🤷‍♀️

From a dependency point of view, the first layout also has the advantage that each user would only have to install the queens_* packages that they actually need and thus only the dependencies that come with these particular packages

@leahaeusel

From a dependency point of view, the first layout also has the advantage that each user would only have to install the queens_* packages that they actually need and thus only the dependencies that come with these particular packages

Small correction. When you install Queens, all the packages (queens_4C, queens_XXX) are installed, but not their dependencies (only those you specified, so pip install .[fourc] or for both pip install .[fourc,XXX]).

This means the packages are installed, but are not guaranteed to work as dependencies might be missing.

It's possible to separate them, but that is complicated to do (therefore not common). Instead, what is commonly done is to raise an error if a package is missing, see for example in dask. So we could do something like this within a module in the queens 4C subpackage:

try: import fourcipp except ImportError as exc: if exc.msg == "No module named 'fourcipp'": raise ImportError("Package fourcipp is not installed, install via <better message here>") from exc raise exc

Thanks for the clarification! I was assuming we would separate the packages in the future, but if this is uncommon and complicated to do, raising an informative error, as you suggested, seems to be a good workaround 👍

I added a similar message to the 4C random fields module

I like that we separate the dependencies for the different packages.
Would this approach also work for large dependencies, such as TensorFlow, throughout the rest of the code (the main QUEENS package)?

Fix will follow in PR queens-py#176

gilrrei · 2025-08-01T19:52:24Z

@maxdinkel @sbrandstaeter @leahaeusel could we get this PR before it diverges too much?

sbrandstaeter

Many thanks to @gilrrei for implementing these important changes.

There is quite a lot going on in this PR, including infrastructure changes and new features. The refactoring of the example simulator functions was missing in the PR descirptions but that's easy to fix. In general, it might be easier to review and to document things if the steps were separated into individual PRs but it also increases overhead so I think we are fine for now.

I have reviewed in great detail, with a focus on naming and documentation, which naturally involves some personal opinions. Goal was however to set this really important feature up for a robust and long lifetime.

src/example_simulator_functions/__init__.py

sbrandstaeter · 2025-08-02T08:44:40Z

src/example_simulator_functions/README.md

@@ -0,0 +1,3 @@
+# Example simulator functions
+
+This package contains a wide range of functions for benchmarking.


Suggested change

This package contains a wide range of functions for benchmarking.

This package provides a suite of analytical functions for method testing, validation and benchmarking.

I was trying to make it a touch more descriptive for people new to the field.

sbrandstaeter · 2025-08-02T08:48:43Z

src/queens_interfaces/fourc/__init__.py

+Modules for interfacing the for multiphysics code 4C (
+https://github.com/4C-multiphysics/4C)


Suggested change

Modules for interfacing the for multiphysics code 4C (

https://github.com/4C-multiphysics/4C)

Modules for interfacing with the 4C multiphysics code (

https://github.com/4C-multiphysics/4C)

sbrandstaeter · 2025-08-02T08:57:54Z

src/queens_interfaces/fourc/random_material_preprocessor.py

+        "The required packages to construct random fields in QUEENS for 4C are not installed."
+        " Please install them via \n pip install -e .[fourc]"


Suggested change

"The required packages to construct random fields in QUEENS for 4C are not installed."

" Please install them via \n pip install -e .[fourc]"

"The packages required to interface with 4C are not installed."

" Please install them via \n pip install -e .[fourc]"

In this way, the error message can be reused if other functionality for the interface is introduced in the future.
The user should know what he was using the interface for anyway.

sbrandstaeter · 2025-08-02T09:02:19Z

src/queens_interfaces/fourc/random_material_preprocessor.py

I like that we separate the dependencies for the different packages.
Would this approach also work for large dependencies, such as TensorFlow, throughout the rest of the code (the main QUEENS package)?

sbrandstaeter · 2025-08-02T10:48:18Z

src/queens_interfaces/fourc/README.md

@@ -0,0 +1,10 @@
+# 4C
+
+This package contains drivers and utilities realted to the for multiphysics code [4C](https://github.com/4C-multiphysics/4C). We like them and we work closely with them.


Suggested change

This package contains drivers and utilities realted to the for multiphysics code [4C](https://github.com/4C-multiphysics/4C). We like them and we work closely with them.

This package contains modules (drivers and utilities) that interface QUEENS with the multiphysics code [4C](https://github.com/4C-multiphysics/4C). We like them and we work closely with them.

sbrandstaeter · 2025-08-02T10:50:35Z

src/queens_interfaces/fourc/README.md

+This package contains drivers and utilities realted to the for multiphysics code [4C](https://github.com/4C-multiphysics/4C). We like them and we work closely with them.
+
+## Material random field interface
+In order to create random material field in combintation with 4C, we require the package [fourcipp](https://github.com/4C-multiphysics/fourcipp). Therefore install QUEENS via (in the QUEENS main directory):


Suggested change

In order to create random material field in combintation with 4C, we require the package [fourcipp](https://github.com/4C-multiphysics/fourcipp). Therefore install QUEENS via (in the QUEENS main directory):

To create random material fields in combination with 4C, we require the package [fourcipp](https://github.com/4C-multiphysics/fourcipp). Therefore, install QUEENS via (in the QUEENS main directory):

sbrandstaeter · 2025-08-02T10:53:44Z

src/queens_interfaces/fourc/random_material_preprocessor.py

+    Path(template_path).write_text(template_data)
+
+
+def extract_by_material_id(material_id):


There might be a better name for this function.

sbrandstaeter · 2025-08-02T10:56:49Z

src/queens_interfaces/fourc/random_material_preprocessor.py

+        dict: with parameter names and element locations
+    """
+    fourc_input = FourCInput.from_4C_yaml(path_to_template)
+    extract_elements(fourc_input, elements_section, extracting_condition)


Suggested change

extract_elements(fourc_input, elements_section, extracting_condition)

Can this be deleted?

sbrandstaeter · 2025-08-02T11:00:50Z

src/queens_interfaces/__init__.py

+"""QUEENS interfaces.

-Modules for preprocessing geometry from external simulation software.
+QUEENS interfaces for different packages.


Suggested change

QUEENS interfaces for different packages.

Interfaces for coupling QUEENS with solvers.

sbrandstaeter

Due to this PR blocking #187, we decided to move forward here and fix my comments regarding naming etc. in a follow-up.

gilrrei mentioned this pull request Jun 26, 2025

Meeting on 03.07.2025 queens-py/queens-meetings#8

Closed

5 tasks

gilrrei added a commit to gilrrei/queens that referenced this pull request Jun 26, 2025

test: skip 4C random field test

6eacf4f

Fix will follow in PR queens-py#176

gilrrei mentioned this pull request Jun 26, 2025

refactor: move to src layout #174

Merged

gilrrei added a commit to gilrrei/queens that referenced this pull request Jun 26, 2025

test: skip 4C random field test

6f75dc6

Fix will follow in PR queens-py#176

leahaeusel reviewed Jun 26, 2025

View reviewed changes

gilrrei added a commit to gilrrei/queens that referenced this pull request Jun 26, 2025

test: skip 4C random field test

a278e1d

Fix will follow in PR queens-py#176

gilrrei force-pushed the refactor_4C_random_fields branch 6 times, most recently from facdff3 to 314d865 Compare July 3, 2025 14:01

gilrrei marked this pull request as ready for review July 3, 2025 14:07

gilrrei force-pushed the refactor_4C_random_fields branch from 314d865 to e965e92 Compare July 3, 2025 14:09

gilrrei marked this pull request as draft July 3, 2025 14:09

refactor: 4C random material fields

923ff83

gilrrei force-pushed the refactor_4C_random_fields branch from e965e92 to fb08a88 Compare July 3, 2025 16:52

gilrrei added 3 commits July 3, 2025 20:16

refactor(example_simulator_functions): make a separate package

6341197

refactor: move 4C related stuff to queens_interfaces/driver

ff64008

docs: add all packages to the documentation

7fc69f9

gilrrei force-pushed the refactor_4C_random_fields branch from fb08a88 to 7fc69f9 Compare July 3, 2025 18:19

gilrrei added 2 commits July 25, 2025 09:41

feat: raise error if additional requirements are not installed

b6a2bb5

test: use pvd data processor for random field test

b8ab9a6

gilrrei force-pushed the refactor_4C_random_fields branch from 55e86f8 to b8ab9a6 Compare July 25, 2025 09:26

gilrrei marked this pull request as ready for review July 25, 2025 09:34

sbrandstaeter requested changes Aug 2, 2025

View reviewed changes

maxdinkel approved these changes Aug 4, 2025

View reviewed changes

sbrandstaeter approved these changes Aug 4, 2025

View reviewed changes

sbrandstaeter merged commit 5d3aee1 into queens-py:main Aug 4, 2025
3 checks passed

sbrandstaeter changed the title ~~Draft: Refactor 4C random fields~~ Refactor 4C random fields Aug 4, 2025

leahaeusel mentioned this pull request Aug 4, 2025

Which functionality of the 4C external geometry is being used? #143

Closed

		@@ -0,0 +1,3 @@
		# Example simulator functions

		This package contains a wide range of functions for benchmarking.

	This package contains a wide range of functions for benchmarking.
	This package provides a suite of analytical functions for method testing, validation and benchmarking.

		Modules for interfacing the for multiphysics code 4C (
		https://github.com/4C-multiphysics/4C)

		"The required packages to construct random fields in QUEENS for 4C are not installed."
		" Please install them via \n pip install -e .[fourc]"

		@@ -0,0 +1,10 @@
		# 4C

		This package contains drivers and utilities realted to the for multiphysics code [4C](https://github.com/4C-multiphysics/4C). We like them and we work closely with them.

	This package contains drivers and utilities realted to the for multiphysics code [4C](https://github.com/4C-multiphysics/4C). We like them and we work closely with them.
	This package contains modules (drivers and utilities) that interface QUEENS with the multiphysics code [4C](https://github.com/4C-multiphysics/4C). We like them and we work closely with them.

	In order to create random material field in combintation with 4C, we require the package [fourcipp](https://github.com/4C-multiphysics/fourcipp). Therefore install QUEENS via (in the QUEENS main directory):
	To create random material fields in combination with 4C, we require the package [fourcipp](https://github.com/4C-multiphysics/fourcipp). Therefore, install QUEENS via (in the QUEENS main directory):

		Path(template_path).write_text(template_data)


		def extract_by_material_id(material_id):

	QUEENS interfaces for different packages.
	Interfaces for coupling QUEENS with solvers.

Conversation

gilrrei commented Jun 25, 2025 • edited by sbrandstaeter Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description and Context:

Related Issues and Pull Requests

Interested Parties

Uh oh!

leahaeusel left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

First proposition

Second proposition

Uh oh!

Choose a reason for hiding this comment

Uh oh!

leahaeusel Jun 26, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

gilrrei Jun 26, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

gilrrei commented Aug 1, 2025

Uh oh!

sbrandstaeter left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

sbrandstaeter left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

gilrrei commented Jun 25, 2025 •

edited by sbrandstaeter

Loading

leahaeusel Jun 26, 2025 •

edited

Loading

gilrrei Jun 26, 2025 •

edited

Loading