Tabulated data; inclussion and usage

[Irvise]

Hi, I am getting started with Tfel/Mfront

I already tried to post this discussion, but it seems it did not pass the Github filter...

My question is regarding tabulated data. I am doing a fairly complex analysis (more on that later) and I would like to be able to include the same data I have available. The data for the properties comes in tabulated form ala:

Young	Temp
100	20
50	200
...	...

How does one work with this type of data? I have not seen any documentation about it anywhere (though I must be honest, I have yet a lot to read). Do I have to create an algebraic representation of the data for it to be processed by Mfront?

The analysis I am trying to do is a elasto-visco-plastic (maybe damage too) in Code_Aster and Abaqus. I am using Abaqus as the primary program and all of its built in tools. The only addition I had to make to Abaqus is the inclusion of a customised CREEP subroutine describing the power law; with dependence on temperature and stress. Code_Aster does not provide much flexibility when it comes to creep nor combined isotropic and kinematic hardening (though VISC_CIN2_CHAB and HAYHURST do come close).

Thank you for your time,
Fernando Oleo Blanco

P.S.: I will open another discussion talking about my case in more detail, this is just for the tabulated data.

[thelfer]

To be honest, material properties are poorly documented in english (The french documentation is a bit better).

For your problem, there is built-in feature to handle material properties given by tabulated data. You may want to open an issue about that.

The main reason is that one must handle how data are interpolated and extrapolated. TFEL/Math provides cubic spline and kriging for example. But no support for linear interpolation !

You'll find attached two examples of how to implement that. The first one is compatible with TFEL-4.0. The second one shall compile with previous versions:

• TestYoungModulus.zip
• TestYoungModulus-without-qt.zip

[Irvise]

Oh great!

First things first, thank you for the quick reply :)

Second, great that math does have a way to work with tabulated data. I will give it a look.

However, as you point out... No linear interpolation? That is a bit strange, specially when you have splines and kriging x) I would like to use linear interpolation mainly to mimic the behaviour that Abaqus has. This would help me validate the model. To me it would also be important to have he data "expanded" from its original range. CA allows constant interpolation or linear interpolation outside of the range. Abaqus has constant interpolation outside of the range.

I will read the french sources. I am not a french speaker, but I can manage :P

Regards,
Fer

Edit: tabulation->interpolation

[thelfer]

However, as you point out... No linear tabulation? That is a bit strange, specially when you have splines and kriging x) I would like to use linear interpolation mainly to mimic the behaviour that Abaqus has.

Yes. I probably though that was too easy to implement, as in the two examples....

The other thing is that I do believe that a dedicated support for tabulated data shall be implemented...

[Irvise]

I do not know how Tfel works inside. But since it is using newer C++ features, it may be able to define a "function" that is just a tabular datatype that can digest data and output a "function" type. The way it works would just be internal state (linear, quadratic, etc)...

My two cents :P

[thelfer]

Yes of course. But the question is about efficiency.
For example, we could precompute coefficients of the cubic spline at compile time, etc...

[Irvise]

Oh, I did not think about that. A cubic may indeed may be more efficient than a linear one... I suppose a linear interpolation has O(n) or O(log n) complexity, compared to a precomputed O(1) for cubic...

[thelfer]

The analysis I am trying to do is a elasto-visco-plastic (maybe damage too) in Code_Aster and Abaqus. I am using Abaqus as the primary program and all of its built in tools. The only addition I had to make to Abaqus is the inclusion of a customised CREEP subroutine describing the power law; with dependence on temperature and stress. Code_Aster does not provide much flexibility when it comes to creep nor combined isotropic and kinematic hardening (though VISC_CIN2_CHAB and HAYHURST do come close).

Di you have a look at the StandardElastoViscoPlasticityBrick ?

[thelfer]

You want to implement this expression ?

ε (s-1) = 1.43×1010 exp (-197,000/8.31 T(K)) (σ(MPa))2.5 (t(s))-0.9

[Irvise]

For the CuCrZr we decided to add up the primary and secondary creep expressions. While that is not correct, the primary creep rate is a couple orders of magnitude greater than the second and it decays with time, so it would be something like:

ε (s-1) = (exp (-197,000/8.31 * T(K)) * (7.56x10^11*(σ(MPa))^3*(t(s))^(-0.92) + XXX)

Where XXX is an interpolation of the second line entry and the third line entry for CuCrZr (their difference is the temperature of the tests). Without the Arrhenius term.

For Cu-OFHC we are just going to use the secondary creep expression listed there (first material entry in the table). Maybe we already see a lot of stress relaxation, which will require the correct data that will be generated in the UK, otherwise, we will have to wait and see.

Edit: we know that the footnote says that we should change from primary to secondary when their strains are the same. However, for stability's sake, we do not want to include an if.

[thelfer]

For the fun, I just implemented the primary creep. This requires a bit of reworking the initial expression as time hardening relation is not a constitutive equation. This is described in the attached note. Adding the secondary creep is trivial.

We could even discuss how to make things even better by replacing material properties with parameters, computing the elastic properties in the behaviour, etc..

Pretty sure that in the end, the implementation is nicer in MFront than in the CREEP module of Abaqus.

TimeHardening.zip
.

[Irvise]

Hi @thelfer,

I took a look at the document you included. Just a minor comment, the first equation, as I have seen it mostly mentioned in the literature is for the creep rate, not the creep. So the creep rate has a time hardening constant (in your document n_t) without -1. But this is not really important, since that would just require shuffling some coefficients around or making small corrections.
Otherwise, thank you for adding the .mfront file with the documented explanation for the derivation, it was nice to see how you approached the problem.

The reason I have not responded earlier is because I started to do some sanity checks on the data I included in an earlier message (the big table one). And after digging more and more on the references and literature, and getting results that were most likely wrong, the strategy has changed.

We have switched to a parametric analysis... It is not great, but it is the best we can do now. So my time has been spent setting up the parametric analysis and data ingestion system... We hope that our results will be an aid to a research team in UK and Italy, who are the ones producing the actual data.

On a personal level, I still hope to develop the material definitions in MFront and work with it in Code_Aster; since CA really needs some extra work on that front, but that has been pushed further in time do to the new load of work.

I am sorry for the delay, but thank you very much none the less! Best regards,
Fer

[thelfer]

@Irvise Thanks for the feed-backs. Let me know if you ever need more help !

[thelfer]

BTW, do not hesitate to use mfront documentation. For example:

$ mfront --help-keyword=MaterialLaw:@Law
$ mfront --help-keyword=MaterialLaw:@Function