Open GiudGiud opened 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.
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?
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
Maybe I mis-understood. Can you give an example of this? "and perform a reduction in the general field transfer main class"
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
Okay, sounds good. As you said, sending the whole field from sub to main would be nice as well.
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.
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
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.
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
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?
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.
So, if we want to train a surrogate to learn field quantities, the training output data should be a vector or vectors.
Yes you could prefer that format. You could also choose to interface with fields.
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?