Questions about Nonlinear elasticity, PROM

[gokhalen]

I'm working with the nonlinear elasticity example:

https://github.com/LLNL/libROM/blob/master/examples/prom/nonlinear_elasticity_global_rom.cpp https://www.librom.net/examples.html

My command line is

./nonlinear_elasticity_global_rom --mesh "../data/beam-hex-nurbs.mesh"  --online -dt 0.01 -tf 5.0 -s 14 -vs 5 -hyp -rvdim 40 -rxdim 10 -hdim 71 -nsr 200 -sc 4.0

I have the following questions:

1) I get relative error of ROM position at t_final as 0.00677831 which agrees well with the error reported in your example. 2) I get relative error of ROM velocity at t_final as 9.58099. Why is this so high? After looking at the code, it seems to be 950% error. 3) What do 'rvdim' , 'rxdim', and 'hdim' mean? Are 'rvdim' and 'rxdim' the number of basis vectors used to approximate the velocity and displacement respectively? And is 'hdim' the number of basis vectors used to approximate the non-linear term?

Edit: Changing the rvdim to 80 in the command line above increases the errors. The position error is 0.00749 and velocity error is 12.33 both of which have increased inspite of number of basis vectors increasing, and I fail to understand this.

Thanks,

Nachiket

[gokhalen]

About the errors reported in the edit above: The position and velocity errors are reported at the final time. Perhaps the errors at the final time are not a monotonic function of the basis size.

[chldkdtn]

Unfortunately, matching velocity is much more difficult job than matching displacement because velocity field is one more derivative of displacement. It is analogous to the fact that it is more difficult to match stress than to match displacement.

[gokhalen]

Thank you, that's interesting.

[gokhalen]

But still, a velocity error of 12.33 (1233% !!!) seems too high.

[chldkdtn]

yeah, that is very high. One way of reducing velocity error is to introduce reduced basis for velocity field as well, which we do not do for this nonlinear elasticity example. However, we do that for Sedov Blast example. Please take a look at that as well. The journal paper for that is here ( https://www.sciencedirect.com/science/article/pii/S0045782521005739 ) and here ( https://www.sciencedirect.com/science/article/pii/S0021999122007185 ).

[gokhalen]

Thanks. I was under the impression that -rvdim 40 introduces a reduced basis for the velocity field as well.

[chldkdtn]

Oh, I missed that. Maybe we are indeed using velocity basis for nonlinear elasticity examples. I think that @axla-io implemented both. Not sure which one is being run currently.

[axla-io]

Hi @gokhalen , can you paste the entire code you use for both the offline and online phase? The -sc parameter scales the load so if you used an -sc value of 0.9 and 1.1 to generate the samples (which is default) and predict at -sc = 4.0, then I'm not at all surprised that that the error is high for the velocity field.

Also the reason your accuracy decreases when you increase the -vdim parameter would be due to overfitting at -sc between 0.9 and 1.1.

Try -sc= 3.9 and -sc = 4.1 for the offline mode with -sc = 4.0 in the online mode.

You can toggle to use only the displacement basis by passing the keyword -xbo. The code above does indeed use both velocity and displacement bases.

[gokhalen]

Hi, @axla-io I've used the example non-linear elasticity code without modifications.

https://github.com/LLNL/libROM/blob/master/examples/prom/nonlinear_elasticity_global_rom.cpp

I've used the instructions for the "Nonlinear elasticity, PROM" without modification

https://www.librom.net/examples.html

Except that I've replaced XXX with 4.0 in the FOM Phase and Online Phase. I'm getting the following errors

Relative error of ROM position (x) at t_final: 5 is 0.00677831 Relative error of ROM velocity (v) at t_final: 5 is 9.58099

Nachiket

[axla-io]

Ah now I see what you mean. My bad, I did not know that the sampling was done for sc = 3.9 and 4.1 in the example. In the documentation I did sc = 0.9 and 1.1 for the offline phase... What happens if you increase the vdim to a much higher number, like 800 or so?

[gokhalen]

Hi @axla-io

Sorry for the late reply. Here is what seems to happen.

With -rvdim 40

Elapsed time for time integration loop 350.778 Relative error of ROM position (x) at t_final: 5 is 0.00677831 Relative error of ROM velocity (v) at t_final: 5 is 9.58099 Elapsed time for entire simulation 421.55

With -rvdim 800

Elapsed time for time integration loop 723.551 Relative error of ROM position (x) at t_final: 5 is 0.00799543 Relative error of ROM velocity (v) at t_final: 5 is 12.6435 Elapsed time for entire simulation 1374.68

So, no joy. Errors in both position and velocity have increased and so has the simulation time (which was to be expected). Is there any theoretical guidance (error estimates etc.) for picking the number of basis vectors correctly? Larger the basis, the lower errors should be, but this doesn't seem to be occurring here. The rest of the simulation parameters were the same as in my first message.

Also, should I be looking at error calculated over all time, instead of error at just the final time-step?

Thanks again for your help,

Nachiket

[axla-io]

This is a really interesting find @gokhalen

It's not always straightforward to tell what -rvdim that will give the best result. There is a function that generates a summary when the bases are merged. That should give a good recommendation. The summary is called something like mergedSV_name.txt I only have LibROM installed on another computer so I can't take a look myself until later in the week / weekend. But I will take a look.

In the meanwhile, could you print the contents of the summary file? Also if you have time, try to see if you get the same behavior for -sc smaller than 1, like -sc = 0.15 and 0.25 for the offline phase and -sc = 0.2 for the ROM?

[gokhalen]

mergedSV_V.txt is

For energy fraction: 0.9, take first 9 of 1002 basis vectors
For energy fraction: 0.99, take first 22 of 1002 basis vectors
For energy fraction: 0.999, take first 39 of 1002 basis vectors
For energy fraction: 0.9999, take first 74 of 1002 basis vectors
For energy fraction: 0.99999, take first 118 of 1002 basis vectors
For energy fraction: 0.999999, take first 156 of 1002 basis vectors
For energy fraction: 1, take first 186 of 1002 basis vectors
Take first 186 of 1002 basis vectors

mergedSV_H.txt is as follows

For energy fraction: 0.9, take first 16 of 1002 basis vectors
For energy fraction: 0.99, take first 36 of 1002 basis vectors
For energy fraction: 0.999, take first 78 of 1002 basis vectors
For energy fraction: 0.9999, take first 125 of 1002 basis vectors
For energy fraction: 0.99999, take first 160 of 1002 basis vectors
For energy fraction: 0.999999, take first 189 of 1002 basis vectors
For energy fraction: 1, take first 213 of 1002 basis vectors
Take first 213 of 1002 basis vectors

mergedSV_X.txt is as follows

For energy fraction: 0.9, take first 8 of 1002 basis vectors
For energy fraction: 0.99, take first 17 of 1002 basis vectors
For energy fraction: 0.999, take first 28 of 1002 basis vectors
For energy fraction: 0.9999, take first 42 of 1002 basis vectors
For energy fraction: 0.99999, take first 70 of 1002 basis vectors
For energy fraction: 0.999999, take first 108 of 1002 basis vectors
For energy fraction: 1, take first 143 of 1002 basis vectors
Take first 143 of 1002 basis vectors

I will run the cases you suggested.

[gokhalen]

Also if you have time, try to see if you get the same behavior for -sc smaller than 1, like -sc = 0.15 and 0.25 for the offline phase and -sc = 0.2 for the ROM?

With -rvdim 40 I get

Elapsed time for time integration loop 407.622
Relative error of ROM position (x) at t_final: 5 is 0.00101237
Relative error of ROM velocity (v) at t_final: 5 is 0.355255
Elapsed time for entire simulation 487.132

With -rvdim 800 we get

Elapsed time for time integration loop 721.193
Relative error of ROM position (x) at t_final: 5 is 0.00100919
Relative error of ROM velocity (v) at t_final: 5 is 0.354556
Elapsed time for entire simulation 1385.16

Results are better. Still 35% error in the velocity is a lot. Perhaps a reason for better results at low values of sc is that there is less non-linearity?

[axla-io]

Thank you @gokhalen for taking the time to do these experiments! Indeed the lower sc gives a lower error and one can intuitively understand why from the IC definition:

void InitialVelocityIC1(const Vector& x, Vector& v)
{
    const int dim = x.Size();
    const double s_eff = s / 80.0;

    v = 0.0;
    v(dim - 1) = -s_eff * sin(s*x(0));
}

Here s = sc. So with larger sc, the beam's initial condition will be a sine wave with higher amplitude and frequency. So the initial condition becomes more and more nonlinear. I invite you to try the following things:

1. pass the keyword -def-ic to get a more simple initial condition defined on the deformation field which is just a linear cantilever (see below):

   void InitialDeformationIC2(const Vector &x, Vector &y) //See MFEM ex19
   {
   // Set the initial configuration. Having this different from the reference
   // configuration can help convergence
   const int dim = x.Size();
   const double s_eff = s;
   y = x;
   y(dim-1) = x(dim - 1) + 0.25*x(0) * s_eff;
   }

2. Try to run your example with configurations as specified in the MergedSV files, i.e. rvdim = 186, rxdim = 143, hdim = 213. Play around with nsr, at some point you should get better results for the velocity field, probably for higher nsr. What I've found is that the different variables interact with each other, e.g. you may need to increase both rxdim and rvdim to get better accuracy for the velocity field, it might not work with just increasing rvdim. Or you might also need to increase hdim.

A final remark on the velocity error is that for structures we are not always interested in accurately predicting the velocity field. It can be useful in structural dynamics, but typically the deformation is more interesting for studying structures under static loading.