communication of field in STK

[mhamadmahdialloush]

Hello,

In an application I am doing that uses STK, I would rather communicate an STK field on a certain STK part, but not all the parts. Is that technically possible?

My application would do calculations for each part alone, so I need that whenever I finish my calculations on a specific part, to communicate the field on that part only.

I am using stk::mesh::communicate_field_data for that purpose. Currently, I am calling the latter function every time I finish the calculation for the part, which is very expensive in fact since it communicates the field over the whole parts.

Thanks!

[cgcgcg]

@alanw0 @trilinos/STK

[alanw0]

@mhamadmahdialloush thanks for the question.

For mesh-entities that are shared or ghosted, the function communicate_field_data sends field-data from the owning MPI rank to non-owning ranks (sharers or ghost-receivers). The non-owning ranks then have the same values as the owner for the given entity and field.

Unfortunately we don't have a function that does this for a particular part.
Why you want to communicate data for each part separately? Is it for algorithmic reasons, or, are you looking for ways to improve performance?

[mhamadmahdialloush]

Thanks for your feedback.

This is an algorithmic issue in fact. The calculations on a certain part might rely on calculations on other parts. So I need that when I do calculations on a certain part, the calculations are finalized and up-to-date on the shared/ghosted entities, because these values might be required for calculations on other parts.

I am obliged at the moment to communicate the field every time I finish calculations on a part unfortunately, which is a waste of time.

[mhamadmahdialloush]

If I may suggest something, and sorry for this late note, it would be more efficient to allow for a field communication over a stk::mesh::PartVector, rather than a Part.

Thanks again!

[alanw0]

Yes I agree, PartVector is the right thing to use here.
Unfortunately my team is kind of swamped, so I can't currently say how soon this can be implemented.

[alanw0]

Can you give me a little more info such as what institution you are from, and very brief description of your application?

[mhamadmahdialloush]

Sure.

I am a post-doctoral researcher in the CFD lab at the American University of Beirut, Lebanon.

We develop CFD methods for general fluid flow problems. We have used STK from Trilinos since couple of years, to read exodus database files, create computational fields, and solve fluid flow models, while many of our infra-structural methods are STK-based API.

Our applications involve mutiple zones, used for instance in conjugate heat transfer problems. In such applications, calculations are done on zone-basis, and not entire mesh-basis. Therefore, we require that fields on zone 1 are up-to-date and synchronized for parallel runs, because zone 2 calculations rely on fields from zone 1.

A zone in our code, is a set of STK parts that are connected together.

[alanw0]

Great, thanks. I'll update you when we are able to get to this.