Iteratable integration type

[TTitscher]

trafficstars

Based on a comment of @Psirus: Would it be nice to have the integrationType be iterable, i.e. for(auto& IP : integrationType)?

[joergfunger]

what certainly be a nice feature.

[TTitscher]

I quickly want to add a problem, unfortunately without a solution in mind. We currently connect a lot of data via the integration point id. For integration point we have:

• natural coordinates and the weight
• a constitutive law, or soon, a PDE integrand
• history data
• cached shape function plus derivative (solved in #36)
• visualization cell definition (could be solved with #35)
• visualization data, like stains, damage, temperature interpolated to an IP for visualization

all connected via the id. Could this even be a code smell? Storing connected data in various std::vector and have a lot of code to keep them updated once the integration type changes?

Anyways, this change may not be a straight forward change in the integration type only, e.g. by introducing an iterator to a std::pair<coord, weight>. Maybe a class IntegrationPoint would be appropriate...

[joergfunger]

The data is stored at different locations but also with different multiplicity, e.g. shape functions are stored only once for all elements, integrands and history data for each ip separately. Are the cached shape functions accessed via the ip (I though the natural coordinates are now used instead?).

I would group these into two classes natural coordinates, weight and visualilzation cells. One possibility would be to combine all integration types into a single class, (with the above variables coordiantes, weight, num_ip, visualization cells). Only when they are constructed, this data is added. Here, it would make sense to create an integration point class.

The IP information per cell/element (we already have this, right IPData?).

2017-06-12 10:14 GMT+02:00 TTitscher [email protected]:

I quickly want to add a problem, unfortunately without a solution in mind. We currently connect a lot of data via the integration point id. For integration point we have:

• natural coordinates and the weight
• a constitutive law, or soon, a PDE integrand
• history data
• cached shape function plus derivative
• visualization cell definition

all connected via the id. Could this even be a code smell? Storing connected data in various std::vector and have a lot of code to keep them updated once the integration type changes?

Anyways, this change may not be a straight forward change in the integration type only, e.g. by introducing an iterator to a std::pair<coord, weight>. Maybe a class IntegrationPoint would be appropriate...

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/nutofem/nuto/issues/40#issuecomment-307720133, or mute the thread https://github.com/notifications/unsubscribe-auth/ATjSJQRxVyv6fzpvD6uZBuMkqIzsmpeUks5sDPNNgaJpZM4Nyj4M .

[TTitscher]

The IP information per cell/element (we already have this, right IPData?).

Yes. The problem I tried to adress is the access to, say, the IPData, via an integration point iterator.

for (auto integrationPoint : mIntegrationType)
    mIpData[???].Add(data); // currently, ??? = integration point id

with a class IP (don't know the details), this could look like:

for (IP& integrationPoint : mIntegrationType)
    integrationPoint.AddData(data);

But this requires much more changes to the code...