idaholab / moose

Multiphysics Object Oriented Simulation Environment
https://www.mooseframework.org
GNU Lesser General Public License v2.1
1.7k stars 1.04k forks source link

Field reduction transfers #23354

Open GiudGiud opened 1 year ago

GiudGiud commented 1 year ago

Reason

With the merge of the general field transfer, we should consider that we could somewhat easily support this. This would be pretty unique, and a strong advantage for UQ studies. We could run multiphysics with uncertain child apps and transfer the average behavior (a field, not just a single scalar, we can already do scalars) to the main app for example.

Design

Add logic in general field and each derived transfer to send multiple origin values for each target point, and perform a reduction in the general field transfer main class.

The main pain point will be sending multiple source points for a single target point, in multiple different transfer epochs. This will require some accounting, especially for computing a standard deviation.

Impact

UQ facilitated

@zachmprince @grmnptr @somu15 any interest on reduction of fields in stochastic tools as opposed to single values? Or are you using reporters to do this right now?

somu15 commented 1 year ago

Yes, we are planning to develop field-output Gaussian Processes in the STM. This capability should be useful for FOGP. Right, now, GPs in STM are limited to scalar outputs.

somu15 commented 1 year ago

From your description, it looks like the field output is reduced to a scalar before sending to the main App. Is this true? Can we send the full field to the main App?

GiudGiud commented 1 year ago

Ah which description did I write wrong? The full fields can be transferred. But right now we bring one value per subapp. We would need to bring multiple values for each subapp

somu15 commented 1 year ago

Maybe I mis-understood. Can you give an example of this? "and perform a reduction in the general field transfer main class"

GiudGiud commented 1 year ago

Subapp 1 sends a field that looks like 'x' Subapp 2 sends a field that looks like '2x' General Field main class performs a reduction: -average, the received field looks like 1.5x -min, the received field looks like x and so on

somu15 commented 1 year ago

Okay, sounds good. As you said, sending the whole field from sub to main would be nice as well.

grmnptr commented 1 year ago

I was planning on working on the FieldTransfer with respect to dimensionality reduction. It might not be super obvious since the vectors might be parallelized differently. Would be cool if we could do it without serialization.

GiudGiud commented 1 year ago

Depends on the serialization you mean. Right now we wont need to serialize on the mesh, it can remain distributed. However for all the app values, this current algorithm will very much need all the child local fields values to be contributed LOCALLY to the app performing the reduction. But we dont need the whole field contributed, just the value to use.

This isnt "as good as" using some sort of prepackaged MPI reduction on the value but it shouldnt be very far off

zachmprince commented 1 year ago

STM has a bunch of Calculator objects that can handle the parallelism of sub-apps, the fields will probably need to be serialized though. Right now we have this capability with scalars (PPs), vectors (VPPs), and vector of vectors (Reporters). I don't think it would be a big ask to extend this to field quantities. Maybe we should promote these calculators to the framework and include them in some sort of transfer.

GiudGiud commented 1 year ago

I agree for copy-like transfer we could use some similar capability as this. I actually suspected you already had this

But for using more advanced algorithms (shape function evaluation, nearest node etc) I think the Transfers frame is where we want to be

somu15 commented 1 year ago

STM has a bunch of Calculator objects that can handle the parallelism of sub-apps, the fields will probably need to be serialized though. Right now we have this capability with scalars (PPs), vectors (VPPs), and vector of vectors (Reporters). I don't think it would be a big ask to extend this to field quantities. Maybe we should promote these calculators to the framework and include them in some sort of transfer.

Maybe a naive question: What's the difference between field quantities and vector of vectors?

GiudGiud commented 1 year ago

A field is like a variable. A vector can be a VectorPostprocessor output, but you could totally form a vector (not even a vector of vector) that has all the DoF values of a variable.

somu15 commented 1 year ago

So, if we want to train a surrogate to learn field quantities, the training output data should be a vector or vectors.

GiudGiud commented 1 year ago

Yes you could prefer that format. You could also choose to interface with fields.