libmesh-users — General information for libmesh users

Re: [Libmesh-users] Periodic boundaries for circular segment domains

[John P. <jwp...@gm...>]

On Thu, Mar 1, 2018 at 9:30 AM, David Knezevic <dav...@ak...>
wrote:

> On Thu, Mar 1, 2018 at 10:50 AM, Roy Stogner <roy...@ic...>
> wrote:
>
> >
> > On Wed, 28 Feb 2018, David Knezevic wrote:
> >
> > I would like to implement a periodic boundary condition on a model with
> >> circular symmetry, e.g. solve on sector of a disk with periodicity. To
> >> implement this it seems like all I'd need to do is subclass
> >> PeriodicBoundary and override get_corresponding_pos() to impose the
> >> appropriate rotation rather than just a translation, and then add the
> >> PeriodicBoundary subclass object to the system in the usual way. Is that
> >> indeed all that's required,
> >>
> >
> > Yes, if it's working correctly!
> >
> > or would we need something more?
> >>
> >
> > If you have something vector or tensor valued, like e.g. a *velocity*
> > variable, and your formulation doesn't already use polar coordinates
> > for the components of that variable, then you're in trouble if you
> > want anything other than 0/90/180/270 degree rotations, because we
> > don't currently have any way to specify a periodic BC for one variable
> > as a weighted sum of other variables.
>
>
> Ah, OK. I was hoping to do cases other than 0/90/180/270 degree rotations,
> and I'm considering elasticity, hence (u,v,w) displacement variables. As a
> result I think the current implementation won't work for me since I'd need
> one variable to be a weighted sum of the others.
>
> I can look into adding this, any suggestions on where to start?
>
>
>
> > Has anyone tried this case before?
> >>
> >
> > We actually have some CI coverage for it thanks to the MOOSE guys:
> > tests/bcs/periodic/orthogonal_pbc_on_square.i
> >
>
> Thanks, I'll have a look.
>
>
> John, regarding this:
>
> We have support for user-defined forward and inverse periodic boundary
> > transform functions in MOOSE if you'd like to check and see how it's done
> > there.
>
>
> I'd be interested to check that, can you point me to the relevant part of
> MOOSE?
>

It's just implemented by overriding get_corresponding_pos() as you said.

https://github.com/idaholab/moose/blob/devel/framework/src/bcs/FunctionPeriodicBoundary.C

-- 
John

Re: [Libmesh-users] Periodic boundaries for circular segment domains

[David K. <dav...@ak...>]

On Thu, Mar 1, 2018 at 11:46 AM, Roy Stogner <roy...@ic...>
wrote:

>
> On Thu, 1 Mar 2018, David Knezevic wrote:
>
> On Thu, Mar 1, 2018 at 10:50 AM, Roy Stogner <roy...@ic...>
>> wrote:
>>
>>       If you have something vector or tensor valued, like e.g. a
>> *velocity*
>>       variable, and your formulation doesn't already use polar coordinates
>>       for the components of that variable, then you're in trouble if you
>>       want anything other than 0/90/180/270 degree rotations, because we
>>       don't currently have any way to specify a periodic BC for one
>> variable
>>       as a weighted sum of other variables.
>>
>>
>> Ah, OK. I was hoping to do cases other than 0/90/180/270 degree
>> rotations, and I'm considering elasticity, hence (u,v,w) displacement
>> variables.
>> As a result I think the current implementation won't work for me since
>> I'd need one variable to be a weighted sum of the others.
>>
>> I can look into adding this,
>>
>
> That would be great!
>
> any suggestions on where to start?
>>
>
> I think the right place to add this would be PeriodicBoundaryBase, but
> I'm not sure what the right way to add it would be.  Right now we have
> a set of variables associated with each periodic boundary, but to do
> this properly we'd also need the user to supply a matrix representing
> the transformation of those variables from one boundary to the other,
> and we'd need to cache the inverse of that matrix for use in a number
> of (often literally!) corner cases where we have to apply constraint
> equations to the "source" DoFs.
>
> compute_periodic_constraints() in fe_base.C is (other than the header
> and caching that matrix inverse) the only function you'd need to
> change, but it's 700 lines of confusing and easily-broken (especially
> in the DistributedMesh case IIRC) code.
>
> We'd probably need to use DenseMatrix to take the matrix inverse, but
> in the short run we'd want to have some semantics like "hold a
> unique_ptr<DenseMatrix>, and if that pointer is null then treat it
> like an identity matrix", to avoid suddenly adding an O(N_variables)
> complexity factor to compute_periodic_constraints.
>

OK, thanks for this input. I'll look into this when I get some time.

David

Re: [Libmesh-users] Periodic boundaries for circular segment domains

[Roy S. <roy...@ic...>]

On Thu, 1 Mar 2018, David Knezevic wrote:

> On Thu, Mar 1, 2018 at 10:50 AM, Roy Stogner <roy...@ic...> wrote:
>
>       If you have something vector or tensor valued, like e.g. a *velocity*
>       variable, and your formulation doesn't already use polar coordinates
>       for the components of that variable, then you're in trouble if you
>       want anything other than 0/90/180/270 degree rotations, because we
>       don't currently have any way to specify a periodic BC for one variable
>       as a weighted sum of other variables.
> 
> 
> Ah, OK. I was hoping to do cases other than 0/90/180/270 degree rotations, and I'm considering elasticity, hence (u,v,w) displacement variables.
> As a result I think the current implementation won't work for me since I'd need one variable to be a weighted sum of the others.
> 
> I can look into adding this,

That would be great!

> any suggestions on where to start?
   
I think the right place to add this would be PeriodicBoundaryBase, but
I'm not sure what the right way to add it would be.  Right now we have
a set of variables associated with each periodic boundary, but to do
this properly we'd also need the user to supply a matrix representing
the transformation of those variables from one boundary to the other,
and we'd need to cache the inverse of that matrix for use in a number
of (often literally!) corner cases where we have to apply constraint
equations to the "source" DoFs.

compute_periodic_constraints() in fe_base.C is (other than the header
and caching that matrix inverse) the only function you'd need to
change, but it's 700 lines of confusing and easily-broken (especially
in the DistributedMesh case IIRC) code.

We'd probably need to use DenseMatrix to take the matrix inverse, but
in the short run we'd want to have some semantics like "hold a
unique_ptr<DenseMatrix>, and if that pointer is null then treat it
like an identity matrix", to avoid suddenly adding an O(N_variables)
complexity factor to compute_periodic_constraints.
---
Roy

Re: [Libmesh-users] Periodic boundaries for circular segment domains

[John P. <jwp...@gm...>]

On Wed, Feb 28, 2018 at 8:11 PM, David Knezevic <dav...@ak...>
wrote:

> I have only seen periodic boundary condition examples in libMesh where
> boundary B is a translation of boundary A. This is what is implemented in
> PeriodicBoundary::get_corresponding_pos(), where we have "return pt +
> translation_vector;"
>
> I would like to implement a periodic boundary condition on a model with
> circular symmetry, e.g. solve on sector of a disk with periodicity. To
> implement this it seems like all I'd need to do is subclass
> PeriodicBoundary and override get_corresponding_pos() to impose the
> appropriate rotation rather than just a translation, and then add the
> PeriodicBoundary subclass object to the system in the usual way. Is that
> indeed all that's required, or would we need something more? Has anyone
> tried this case before?
>

We have support for user-defined forward and inverse periodic boundary
transform functions in MOOSE if you'd like to check and see how it's done
there.

-- 
John

Re: [Libmesh-users] Periodic boundaries for circular segment domains

[David K. <dav...@ak...>]

On Thu, Mar 1, 2018 at 10:50 AM, Roy Stogner <roy...@ic...>
wrote:

>
> On Wed, 28 Feb 2018, David Knezevic wrote:
>
> I would like to implement a periodic boundary condition on a model with
>> circular symmetry, e.g. solve on sector of a disk with periodicity. To
>> implement this it seems like all I'd need to do is subclass
>> PeriodicBoundary and override get_corresponding_pos() to impose the
>> appropriate rotation rather than just a translation, and then add the
>> PeriodicBoundary subclass object to the system in the usual way. Is that
>> indeed all that's required,
>>
>
> Yes, if it's working correctly!
>
> or would we need something more?
>>
>
> If you have something vector or tensor valued, like e.g. a *velocity*
> variable, and your formulation doesn't already use polar coordinates
> for the components of that variable, then you're in trouble if you
> want anything other than 0/90/180/270 degree rotations, because we
> don't currently have any way to specify a periodic BC for one variable
> as a weighted sum of other variables.


Ah, OK. I was hoping to do cases other than 0/90/180/270 degree rotations,
and I'm considering elasticity, hence (u,v,w) displacement variables. As a
result I think the current implementation won't work for me since I'd need
one variable to be a weighted sum of the others.

I can look into adding this, any suggestions on where to start?



> Has anyone tried this case before?
>>
>
> We actually have some CI coverage for it thanks to the MOOSE guys:
> tests/bcs/periodic/orthogonal_pbc_on_square.i
>

Thanks, I'll have a look.


John, regarding this:

We have support for user-defined forward and inverse periodic boundary
> transform functions in MOOSE if you'd like to check and see how it's done
> there.


I'd be interested to check that, can you point me to the relevant part of
MOOSE?

Thanks,
David

Re: [Libmesh-users] Unusual results of transient RB with 7 parameters

[吴家桦Gauvain <cau...@gm...>]

I solve with truth_solve and find the result is also bizarre, which is the
same as the previous ones. I may have to check the matrix assembly. Thank
you so much for your help.

Gauvain

2018-02-28 0:44 GMT+08:00 David Knezevic <dav...@ak...>:

> On Tue, Feb 27, 2018 at 9:48 AM, 吴家桦Gauvain <cau...@gm...>
> wrote:
>
>> Still a long way to go... Would you please tell me how to view the "truth
>> solve" solution?
>>
>
> RBConstruction::truth_solve take an int argument. If that's negative then
> it doesn't plot. If it's positive then it plots the "truth solution" in the
> steady-state case. In the transient case, if you set the int to be 10, for
> example, then it will plot every 10th time step.
>
> I suggest you do some solves with truth_solve directly and look at the
> solution since that will allow you to set up specific parameters and do a
> solve and check that it looks right. Note that train_reduced_basis also
> calls truth_solve and it has the int argument set to -1 so that it doesn't
> plot anything.
>
> David
>
> P.S. As usual, make sure you're using a direct solver (e.g. MUMPS) during
> debugging to eliminate incomplete solver convergence as one possible source
> of problems.
>
>
> 2018-02-27 22:00 GMT+08:00 David Knezevic <dav...@ak...>:
>>
>>> On Tue, Feb 27, 2018 at 8:55 AM, 吴家桦Gauvain <cau...@gm...>
>>> wrote:
>>>
>>>> Thanks for replying.
>>>>
>>>> I did omit the inertia terms in my PDE. Regarding the greedy
>>>> convergence of 7 parameter transient case, the maximum error bound
>>>> decreases as usual, from about 40000 to 0.00197 but the result is abnormal
>>>> like what is described in my first mail. In fact, 3 parameter (thermal
>>>> conditions) transient case works well and so does 7 parameter steady case.
>>>> The problem arises when I attempt to combine them together by replacing the
>>>> assembly function of the stiffness matrix in 3 parameter transient case
>>>> with that of 7 parameter steady case.
>>>>
>>>
>>> Sounds like you need to do some debugging... e.g. set parameters to have
>>> min=max and see if it's still abnormal, or view the "truth solve" solution
>>> or other things like that to try to identify where the problem is.
>>>
>>> David
>>>
>>>
>>>
>>>
>>>> 2018-02-27 21:21 GMT+08:00 David Knezevic <dav...@ak...>:
>>>>
>>>>> On Tue, Feb 27, 2018 at 4:03 AM, 吴家桦Gauvain <cau...@gm...>
>>>>> wrote:
>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> I am trying to make a transient thermoelastic RB model. Both Internal
>>>>>> heat
>>>>>> flux and external heat exchange described by Newton's law of
>>>>>> cooling(Robin
>>>>>> boundary condition) are considered. It works well when the three
>>>>>> thermal
>>>>>> conditions (heat flux, heat transfer coefficient and ambient
>>>>>> temperature)
>>>>>> are chosen as parameters. However, abnormal results are observed when
>>>>>> the
>>>>>> material properties (Young's modulus, Poisson's ratio, thermal
>>>>>> expansion
>>>>>> coefficient and heat conductivity) are added as parameters: Three
>>>>>> displacement components remain 0 and the temperature increases
>>>>>> drastically
>>>>>> as the time goes by. What's more, I notice that the difference
>>>>>> between the
>>>>>> first and the second POD eigenvalues is extremely large:
>>>>>>
>>>>>> POD Eigenvalues:
>>>>>> eigenvalue 0 = 4.4536e+08
>>>>>> eigenvalue 1 = 2.45303e-07
>>>>>> ...
>>>>>> last eigenvalue = -1.90536e-07
>>>>>>
>>>>>> The matrix assembly should not pose problem because it runs well in
>>>>>> steady
>>>>>> case and I simply copy the assembly functions without any
>>>>>> modification.
>>>>>> Thus I am really confused and I cannot figure out where the problem
>>>>>> is.
>>>>>> Could you give me some suggestions? Thanks a lot.
>>>>>>
>>>>>
>>>>> Good to hear that it works well in the steady case.
>>>>>
>>>>> Regarding the transient case, I have a few comments:
>>>>>
>>>>> - The default implementation for transient RB that is used in the
>>>>> examples is intended for parabolic PDEs, like the heat equation. I guess
>>>>> your PDE is parabolic since you omit the hyperbolic parts (i.e. the inertia
>>>>> terms) from the elasticity part of the system?
>>>>>
>>>>> - 7 parameters is quite a lot of parameters, so you may just be having
>>>>> trouble with greedy convergence?
>>>>>
>>>>> My main suggestion would be to try to get a simple transient problem
>>>>> working first, then add more complexity to it until you reach the problem
>>>>> that you're interested in, e.g. you could start with the heat equation and
>>>>> then add elasticity terms.
>>>>>
>>>>> Regards,
>>>>> David
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>>
>>>
>>>
>>
>>
>> --
>> *吴家桦 Gauvain*
>> *Mobile:13316300622 <(331)%20630-0622>*
>> *Email:g <gau...@fo...>auv...@gm...
>> <auv...@gm...>*
>> 中山大学中法核工程与技术学院学生
>> Institut Franco-Chinois de l'Energie
>> Nucléaire, L'université Sun Yat-sen
>>
>
>


-- 
*吴家桦 Gauvain*
*Mobile:13316300622*
*Email:g <gau...@fo...>auv...@gm...
<auv...@gm...>*
中山大学中法核工程与技术学院学生
Institut Franco-Chinois de l'Energie
Nucléaire, L'université Sun Yat-sen

[Libmesh-users] Periodic boundaries for circular segment domains

[David K. <dav...@ak...>]

I have only seen periodic boundary condition examples in libMesh where
boundary B is a translation of boundary A. This is what is implemented in
PeriodicBoundary::get_corresponding_pos(), where we have "return pt +
translation_vector;"

I would like to implement a periodic boundary condition on a model with
circular symmetry, e.g. solve on sector of a disk with periodicity. To
implement this it seems like all I'd need to do is subclass
PeriodicBoundary and override get_corresponding_pos() to impose the
appropriate rotation rather than just a translation, and then add the
PeriodicBoundary subclass object to the system in the usual way. Is that
indeed all that's required, or would we need something more? Has anyone
tried this case before?

Thanks,
David

[Libmesh-users] question about mesh free interpolation

[Michael P. <mpo...@pu...>]

Dear Libmesh developers,

I'm going to use class InverseDistanceInterpolation.

I need to interpolate many times different data defined on the same set 
of point. Is it possible to have such code:

InverseDistanceInterpolation idi(comm_in);

idi.set_field_variables(names);

idi.get_source_points() = initial_points;

idi.prepare_for_use();

for (int it = 0; it < 100; it++)

{

     idi.get_source_points() = source_vals;

     idi.interpolate_field_data(names, tgt_pts, tgt_vals);

}

Thank you,

Michael.

Re: [Libmesh-users] Unusual results of transient RB with 7 parameters

[David K. <dav...@ak...>]

On Tue, Feb 27, 2018 at 9:48 AM, 吴家桦Gauvain <cau...@gm...> wrote:

> Still a long way to go... Would you please tell me how to view the "truth
> solve" solution?
>

RBConstruction::truth_solve take an int argument. If that's negative then
it doesn't plot. If it's positive then it plots the "truth solution" in the
steady-state case. In the transient case, if you set the int to be 10, for
example, then it will plot every 10th time step.

I suggest you do some solves with truth_solve directly and look at the
solution since that will allow you to set up specific parameters and do a
solve and check that it looks right. Note that train_reduced_basis also
calls truth_solve and it has the int argument set to -1 so that it doesn't
plot anything.

David

P.S. As usual, make sure you're using a direct solver (e.g. MUMPS) during
debugging to eliminate incomplete solver convergence as one possible source
of problems.


2018-02-27 22:00 GMT+08:00 David Knezevic <dav...@ak...>:
>
>> On Tue, Feb 27, 2018 at 8:55 AM, 吴家桦Gauvain <cau...@gm...>
>> wrote:
>>
>>> Thanks for replying.
>>>
>>> I did omit the inertia terms in my PDE. Regarding the greedy convergence
>>> of 7 parameter transient case, the maximum error bound decreases as usual,
>>> from about 40000 to 0.00197 but the result is abnormal like what is
>>> described in my first mail. In fact, 3 parameter (thermal conditions)
>>> transient case works well and so does 7 parameter steady case. The problem
>>> arises when I attempt to combine them together by replacing the assembly
>>> function of the stiffness matrix in 3 parameter transient case with that of
>>> 7 parameter steady case.
>>>
>>
>> Sounds like you need to do some debugging... e.g. set parameters to have
>> min=max and see if it's still abnormal, or view the "truth solve" solution
>> or other things like that to try to identify where the problem is.
>>
>> David
>>
>>
>>
>>
>>> 2018-02-27 21:21 GMT+08:00 David Knezevic <dav...@ak...>:
>>>
>>>> On Tue, Feb 27, 2018 at 4:03 AM, 吴家桦Gauvain <cau...@gm...>
>>>> wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> I am trying to make a transient thermoelastic RB model. Both Internal
>>>>> heat
>>>>> flux and external heat exchange described by Newton's law of
>>>>> cooling(Robin
>>>>> boundary condition) are considered. It works well when the three
>>>>> thermal
>>>>> conditions (heat flux, heat transfer coefficient and ambient
>>>>> temperature)
>>>>> are chosen as parameters. However, abnormal results are observed when
>>>>> the
>>>>> material properties (Young's modulus, Poisson's ratio, thermal
>>>>> expansion
>>>>> coefficient and heat conductivity) are added as parameters: Three
>>>>> displacement components remain 0 and the temperature increases
>>>>> drastically
>>>>> as the time goes by. What's more, I notice that the difference between
>>>>> the
>>>>> first and the second POD eigenvalues is extremely large:
>>>>>
>>>>> POD Eigenvalues:
>>>>> eigenvalue 0 = 4.4536e+08
>>>>> eigenvalue 1 = 2.45303e-07
>>>>> ...
>>>>> last eigenvalue = -1.90536e-07
>>>>>
>>>>> The matrix assembly should not pose problem because it runs well in
>>>>> steady
>>>>> case and I simply copy the assembly functions without any modification.
>>>>> Thus I am really confused and I cannot figure out where the problem is.
>>>>> Could you give me some suggestions? Thanks a lot.
>>>>>
>>>>
>>>> Good to hear that it works well in the steady case.
>>>>
>>>> Regarding the transient case, I have a few comments:
>>>>
>>>> - The default implementation for transient RB that is used in the
>>>> examples is intended for parabolic PDEs, like the heat equation. I guess
>>>> your PDE is parabolic since you omit the hyperbolic parts (i.e. the inertia
>>>> terms) from the elasticity part of the system?
>>>>
>>>> - 7 parameters is quite a lot of parameters, so you may just be having
>>>> trouble with greedy convergence?
>>>>
>>>> My main suggestion would be to try to get a simple transient problem
>>>> working first, then add more complexity to it until you reach the problem
>>>> that you're interested in, e.g. you could start with the heat equation and
>>>> then add elasticity terms.
>>>>
>>>> Regards,
>>>> David
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>>
>>
>>
>
>
> --
> *吴家桦 Gauvain*
> *Mobile:13316300622 <(331)%20630-0622>*
> *Email:g <gau...@fo...>auv...@gm...
> <auv...@gm...>*
> 中山大学中法核工程与技术学院学生
> Institut Franco-Chinois de l'Energie
> Nucléaire, L'université Sun Yat-sen
>

Re: [Libmesh-users] Unusual results of transient RB with 7 parameters

[吴家桦Gauvain <cau...@gm...>]

Still a long way to go... Would you please tell me how to view the "truth
solve" solution?

Gauvain

2018-02-27 22:00 GMT+08:00 David Knezevic <dav...@ak...>:

> On Tue, Feb 27, 2018 at 8:55 AM, 吴家桦Gauvain <cau...@gm...>
> wrote:
>
>> Thanks for replying.
>>
>> I did omit the inertia terms in my PDE. Regarding the greedy convergence
>> of 7 parameter transient case, the maximum error bound decreases as usual,
>> from about 40000 to 0.00197 but the result is abnormal like what is
>> described in my first mail. In fact, 3 parameter (thermal conditions)
>> transient case works well and so does 7 parameter steady case. The problem
>> arises when I attempt to combine them together by replacing the assembly
>> function of the stiffness matrix in 3 parameter transient case with that of
>> 7 parameter steady case.
>>
>
> Sounds like you need to do some debugging... e.g. set parameters to have
> min=max and see if it's still abnormal, or view the "truth solve" solution
> or other things like that to try to identify where the problem is.
>
> David
>
>
>
>
>> 2018-02-27 21:21 GMT+08:00 David Knezevic <dav...@ak...>:
>>
>>> On Tue, Feb 27, 2018 at 4:03 AM, 吴家桦Gauvain <cau...@gm...>
>>> wrote:
>>>
>>>> Hi all,
>>>>
>>>> I am trying to make a transient thermoelastic RB model. Both Internal
>>>> heat
>>>> flux and external heat exchange described by Newton's law of
>>>> cooling(Robin
>>>> boundary condition) are considered. It works well when the three thermal
>>>> conditions (heat flux, heat transfer coefficient and ambient
>>>> temperature)
>>>> are chosen as parameters. However, abnormal results are observed when
>>>> the
>>>> material properties (Young's modulus, Poisson's ratio, thermal expansion
>>>> coefficient and heat conductivity) are added as parameters: Three
>>>> displacement components remain 0 and the temperature increases
>>>> drastically
>>>> as the time goes by. What's more, I notice that the difference between
>>>> the
>>>> first and the second POD eigenvalues is extremely large:
>>>>
>>>> POD Eigenvalues:
>>>> eigenvalue 0 = 4.4536e+08
>>>> eigenvalue 1 = 2.45303e-07
>>>> ...
>>>> last eigenvalue = -1.90536e-07
>>>>
>>>> The matrix assembly should not pose problem because it runs well in
>>>> steady
>>>> case and I simply copy the assembly functions without any modification.
>>>> Thus I am really confused and I cannot figure out where the problem is.
>>>> Could you give me some suggestions? Thanks a lot.
>>>>
>>>
>>> Good to hear that it works well in the steady case.
>>>
>>> Regarding the transient case, I have a few comments:
>>>
>>> - The default implementation for transient RB that is used in the
>>> examples is intended for parabolic PDEs, like the heat equation. I guess
>>> your PDE is parabolic since you omit the hyperbolic parts (i.e. the inertia
>>> terms) from the elasticity part of the system?
>>>
>>> - 7 parameters is quite a lot of parameters, so you may just be having
>>> trouble with greedy convergence?
>>>
>>> My main suggestion would be to try to get a simple transient problem
>>> working first, then add more complexity to it until you reach the problem
>>> that you're interested in, e.g. you could start with the heat equation and
>>> then add elasticity terms.
>>>
>>> Regards,
>>> David
>>>
>>>
>>>
>>
>>
>> --
>>
>
>


-- 
*吴家桦 Gauvain*
*Mobile:13316300622*
*Email:g <gau...@fo...>auv...@gm...
<auv...@gm...>*
中山大学中法核工程与技术学院学生
Institut Franco-Chinois de l'Energie
Nucléaire, L'université Sun Yat-sen

Re: [Libmesh-users] Unusual results of transient RB with 7 parameters

[David K. <dav...@ak...>]

On Tue, Feb 27, 2018 at 8:55 AM, 吴家桦Gauvain <cau...@gm...> wrote:

> Thanks for replying.
>
> I did omit the inertia terms in my PDE. Regarding the greedy convergence
> of 7 parameter transient case, the maximum error bound decreases as usual,
> from about 40000 to 0.00197 but the result is abnormal like what is
> described in my first mail. In fact, 3 parameter (thermal conditions)
> transient case works well and so does 7 parameter steady case. The problem
> arises when I attempt to combine them together by replacing the assembly
> function of the stiffness matrix in 3 parameter transient case with that of
> 7 parameter steady case.
>

Sounds like you need to do some debugging... e.g. set parameters to have
min=max and see if it's still abnormal, or view the "truth solve" solution
or other things like that to try to identify where the problem is.

David




> 2018-02-27 21:21 GMT+08:00 David Knezevic <dav...@ak...>:
>
>> On Tue, Feb 27, 2018 at 4:03 AM, 吴家桦Gauvain <cau...@gm...>
>> wrote:
>>
>>> Hi all,
>>>
>>> I am trying to make a transient thermoelastic RB model. Both Internal
>>> heat
>>> flux and external heat exchange described by Newton's law of
>>> cooling(Robin
>>> boundary condition) are considered. It works well when the three thermal
>>> conditions (heat flux, heat transfer coefficient and ambient temperature)
>>> are chosen as parameters. However, abnormal results are observed when the
>>> material properties (Young's modulus, Poisson's ratio, thermal expansion
>>> coefficient and heat conductivity) are added as parameters: Three
>>> displacement components remain 0 and the temperature increases
>>> drastically
>>> as the time goes by. What's more, I notice that the difference between
>>> the
>>> first and the second POD eigenvalues is extremely large:
>>>
>>> POD Eigenvalues:
>>> eigenvalue 0 = 4.4536e+08
>>> eigenvalue 1 = 2.45303e-07
>>> ...
>>> last eigenvalue = -1.90536e-07
>>>
>>> The matrix assembly should not pose problem because it runs well in
>>> steady
>>> case and I simply copy the assembly functions without any modification.
>>> Thus I am really confused and I cannot figure out where the problem is.
>>> Could you give me some suggestions? Thanks a lot.
>>>
>>
>> Good to hear that it works well in the steady case.
>>
>> Regarding the transient case, I have a few comments:
>>
>> - The default implementation for transient RB that is used in the
>> examples is intended for parabolic PDEs, like the heat equation. I guess
>> your PDE is parabolic since you omit the hyperbolic parts (i.e. the inertia
>> terms) from the elasticity part of the system?
>>
>> - 7 parameters is quite a lot of parameters, so you may just be having
>> trouble with greedy convergence?
>>
>> My main suggestion would be to try to get a simple transient problem
>> working first, then add more complexity to it until you reach the problem
>> that you're interested in, e.g. you could start with the heat equation and
>> then add elasticity terms.
>>
>> Regards,
>> David
>>
>>
>>
>
>
> --
>

Re: [Libmesh-users] Unusual results of transient RB with 7 parameters

[吴家桦Gauvain <cau...@gm...>]

Thanks for replying.

I did omit the inertia terms in my PDE. Regarding the greedy convergence of
7 parameter transient case, the maximum error bound decreases as usual,
from about 40000 to 0.00197 but the result is abnormal like what is
described in my first mail. In fact, 3 parameter (thermal conditions)
transient case works well and so does 7 parameter steady case. The problem
arises when I attempt to combine them together by replacing the assembly
function of the stiffness matrix in 3 parameter transient case with that of
7 parameter steady case.

Regards,
Gauvain

2018-02-27 21:21 GMT+08:00 David Knezevic <dav...@ak...>:

> On Tue, Feb 27, 2018 at 4:03 AM, 吴家桦Gauvain <cau...@gm...>
> wrote:
>
>> Hi all,
>>
>> I am trying to make a transient thermoelastic RB model. Both Internal heat
>> flux and external heat exchange described by Newton's law of cooling(Robin
>> boundary condition) are considered. It works well when the three thermal
>> conditions (heat flux, heat transfer coefficient and ambient temperature)
>> are chosen as parameters. However, abnormal results are observed when the
>> material properties (Young's modulus, Poisson's ratio, thermal expansion
>> coefficient and heat conductivity) are added as parameters: Three
>> displacement components remain 0 and the temperature increases drastically
>> as the time goes by. What's more, I notice that the difference between the
>> first and the second POD eigenvalues is extremely large:
>>
>> POD Eigenvalues:
>> eigenvalue 0 = 4.4536e+08
>> eigenvalue 1 = 2.45303e-07
>> ...
>> last eigenvalue = -1.90536e-07
>>
>> The matrix assembly should not pose problem because it runs well in steady
>> case and I simply copy the assembly functions without any modification.
>> Thus I am really confused and I cannot figure out where the problem is.
>> Could you give me some suggestions? Thanks a lot.
>>
>
> Good to hear that it works well in the steady case.
>
> Regarding the transient case, I have a few comments:
>
> - The default implementation for transient RB that is used in the examples
> is intended for parabolic PDEs, like the heat equation. I guess your PDE is
> parabolic since you omit the hyperbolic parts (i.e. the inertia terms) from
> the elasticity part of the system?
>
> - 7 parameters is quite a lot of parameters, so you may just be having
> trouble with greedy convergence?
>
> My main suggestion would be to try to get a simple transient problem
> working first, then add more complexity to it until you reach the problem
> that you're interested in, e.g. you could start with the heat equation and
> then add elasticity terms.
>
> Regards,
> David
>
>
>


--

Re: [Libmesh-users] Unusual results of transient RB with 7 parameters

[David K. <dav...@ak...>]

On Tue, Feb 27, 2018 at 4:03 AM, 吴家桦Gauvain <cau...@gm...> wrote:

> Hi all,
>
> I am trying to make a transient thermoelastic RB model. Both Internal heat
> flux and external heat exchange described by Newton's law of cooling(Robin
> boundary condition) are considered. It works well when the three thermal
> conditions (heat flux, heat transfer coefficient and ambient temperature)
> are chosen as parameters. However, abnormal results are observed when the
> material properties (Young's modulus, Poisson's ratio, thermal expansion
> coefficient and heat conductivity) are added as parameters: Three
> displacement components remain 0 and the temperature increases drastically
> as the time goes by. What's more, I notice that the difference between the
> first and the second POD eigenvalues is extremely large:
>
> POD Eigenvalues:
> eigenvalue 0 = 4.4536e+08
> eigenvalue 1 = 2.45303e-07
> ...
> last eigenvalue = -1.90536e-07
>
> The matrix assembly should not pose problem because it runs well in steady
> case and I simply copy the assembly functions without any modification.
> Thus I am really confused and I cannot figure out where the problem is.
> Could you give me some suggestions? Thanks a lot.
>

Good to hear that it works well in the steady case.

Regarding the transient case, I have a few comments:

- The default implementation for transient RB that is used in the examples
is intended for parabolic PDEs, like the heat equation. I guess your PDE is
parabolic since you omit the hyperbolic parts (i.e. the inertia terms) from
the elasticity part of the system?

- 7 parameters is quite a lot of parameters, so you may just be having
trouble with greedy convergence?

My main suggestion would be to try to get a simple transient problem
working first, then add more complexity to it until you reach the problem
that you're interested in, e.g. you could start with the heat equation and
then add elasticity terms.

Regards,
David

[Libmesh-users] Unusual results of transient RB with 7 parameters

[吴家桦Gauvain <cau...@gm...>]

Hi all,

I am trying to make a transient thermoelastic RB model. Both Internal heat
flux and external heat exchange described by Newton's law of cooling(Robin
boundary condition) are considered. It works well when the three thermal
conditions (heat flux, heat transfer coefficient and ambient temperature)
are chosen as parameters. However, abnormal results are observed when the
material properties (Young's modulus, Poisson's ratio, thermal expansion
coefficient and heat conductivity) are added as parameters: Three
displacement components remain 0 and the temperature increases drastically
as the time goes by. What's more, I notice that the difference between the
first and the second POD eigenvalues is extremely large:

POD Eigenvalues:
eigenvalue 0 = 4.4536e+08
eigenvalue 1 = 2.45303e-07
...
last eigenvalue = -1.90536e-07

The matrix assembly should not pose problem because it runs well in steady
case and I simply copy the assembly functions without any modification.
Thus I am really confused and I cannot figure out where the problem is.
Could you give me some suggestions? Thanks a lot.

Gauvain
--

[Libmesh-users] Discontinuous base with springs

[Renato P. <re...@gm...>]

Hi

I need to represent fractures in my elastic system. For that I would
like to use a discontinuous base (L2_LAGRANGE variable?) and tie
overlapping dofs with a penalty function, representing springs
(probably weakly).

Is there any example to follow?
How can I efficiently find the dofs to tie?
I should then use the "add_constraint_row", right?

I found another application in the list that uses the
"find_nodal_neighbors" function.
Is that the right thing to do?

Thanks
Renato

Re: [Libmesh-users] Cohesive elements support?

[Renato P. <re...@gm...>]

Hi all

Did you guys get to a conclusion on this topic? I am very interested in that and will be glad to hear your advices. Can I help in any sense?

Rgds,
Renato

Em 12 de fev de 2018, à(s) 12:41, John Peterson <jwp...@gm...> escreveu:

> On Mon, Feb 12, 2018 at 8:17 AM, Rovinelli, Andrea <aro...@an...>
> wrote:
> 
>> Hi there,
>> I’m new to libmesh so this may be a silly question but from the doxygen I
>> wasn’t able to get an answer.
>> Does libmesh support cohesive elements?
>> If not why (There is another way to implement a cohesive zone in libmesh)?
>> Also can somebody give me some hint on how to implement them? What do I
>> need to subclass and the major modification needed?
>> 
> 
> Andrea,
> 
> libMesh does not currently support cohesive elements. I suggest you keep
> working with Ben Spencer and Wen Jiang on this topic to identify what
> changes will be required in libmesh to support them.
> 
> -- 
> John
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Libmesh-users mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libmesh-users

Re: [Libmesh-users] Cohesive elements support?

[Renato P. <re...@gm...>]

Hi Andrea,

Thanks for the answer!

Let me try to broaden a little this thread:

I can imagine this has been done before in application code. So ...
Does anyone have examples or pointers to suggestions of
straightforward implementations of cohesive zones in libmesh?
Do you guys know someone I could e-mail directly - perhaps published
papers or so?

Thanks once again!
Renato

On Wed, Feb 14, 2018 at 1:39 PM, Rovinelli, Andrea <aro...@an...> wrote:
> Dear Renato,
>
> I'm not working directly with libmesh, but rather I'm using the MOOSE
> framework (http://mooseframework.org), which is based on libemesh. My
> understanding is that libmesh does not support cohesive elements and, as
> today, there is no plan to implement this feature because the same results
> can be achieved by using interface and constraints.
>
> I'm working on implementing a cohesive zone model in MOOSE but I don't know
> if what I'm doing can be translated to libmesh directly, as I'm not really
> familiar with it.
>
>
> John please correct me if I said something wrong.
>
>
> Hope this help.
>
> ________________________________
> From: Renato Poli <re...@gm...>
> Sent: Wednesday, February 14, 2018 8:13:37 AM
> To: John Peterson
> Cc: Rovinelli, Andrea; lib...@li...
> Subject: Re: [Libmesh-users] Cohesive elements support?
>
> Hi all
>
> Did you guys get to a conclusion on this topic? I am very interested in that
> and will be glad to hear your advices. Can I help in any sense?
>
> Rgds,
> Renato
>
> Em 12 de fev de 2018, à(s) 12:41, John Peterson <jwp...@gm...>
> escreveu:
>
>> On Mon, Feb 12, 2018 at 8:17 AM, Rovinelli, Andrea <aro...@an...>
>> wrote:
>>
>>> Hi there,
>>> I’m new to libmesh so this may be a silly question but from the doxygen I
>>> wasn’t able to get an answer.
>>> Does libmesh support cohesive elements?
>>> If not why (There is another way to implement a cohesive zone in
>>> libmesh)?
>>> Also can somebody give me some hint on how to implement them? What do I
>>> need to subclass and the major modification needed?
>>>
>>
>> Andrea,
>>
>> libMesh does not currently support cohesive elements. I suggest you keep
>> working with Ben Spencer and Wen Jiang on this topic to identify what
>> changes will be required in libmesh to support them.
>>
>> --
>> John
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> Libmesh-users mailing list
>> Lib...@li...
>> https://lists.sourceforge.net/lists/listinfo/libmesh-users

Re: [Libmesh-users] Cohesive elements support?

[Rovinelli, A. <aro...@an...>]

Dear Renato,

I'm not working directly with libmesh, but rather I'm using the MOOSE framework (http://mooseframework.org), which is based on libemesh. My understanding is that libmesh does not support cohesive elements and, as today, there is no plan to implement this feature because the same results can be achieved by using interface and constraints.

I'm working on implementing a cohesive zone model in MOOSE but I don't know if what I'm doing can be translated to libmesh directly, as I'm not really familiar with it.


John please correct me if I said something wrong.


Hope this help.

________________________________
From: Renato Poli <re...@gm...>
Sent: Wednesday, February 14, 2018 8:13:37 AM
To: John Peterson
Cc: Rovinelli, Andrea; lib...@li...
Subject: Re: [Libmesh-users] Cohesive elements support?

Hi all

Did you guys get to a conclusion on this topic? I am very interested in that and will be glad to hear your advices. Can I help in any sense?

Rgds,
Renato

Em 12 de fev de 2018, à(s) 12:41, John Peterson <jwp...@gm...> escreveu:

> On Mon, Feb 12, 2018 at 8:17 AM, Rovinelli, Andrea <aro...@an...>
> wrote:
>
>> Hi there,
>> I’m new to libmesh so this may be a silly question but from the doxygen I
>> wasn’t able to get an answer.
>> Does libmesh support cohesive elements?
>> If not why (There is another way to implement a cohesive zone in libmesh)?
>> Also can somebody give me some hint on how to implement them? What do I
>> need to subclass and the major modification needed?
>>
>
> Andrea,
>
> libMesh does not currently support cohesive elements. I suggest you keep
> working with Ben Spencer and Wen Jiang on this topic to identify what
> changes will be required in libmesh to support them.
>
> --
> John
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Libmesh-users mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libmesh-users

Re: [Libmesh-users] Is LIBS treated correctly?

[Victor E. <eij...@ta...>]

On Feb 12, 2018, at 5:46 PM, John Peterson <jwp...@gm...<mailto:jwp...@gm...>> wrote:

 try putting your custom library+path in the $libmesh_LDFLAGS environment variable

Mixed case like that?

It’s not working, and I have no idea what it stumbles on as the output does not contain the commandline.

Again, log attached.

Victor.

Re: [Libmesh-users] 1D/2D elements in 3D space

[Roy S. <roy...@ic...>]

On Mon, 12 Feb 2018, Manav Bhatia wrote:

> So, would the shape function derivatives account the orientation of the element?
>
> For instance, a 1D element oriented along:   x-axis   vs   y-axis   vs   x=y line.
>
> In all cases, there is only one shape function defined along the
> element coordinate. But its derivative wrt x and y will vary. Is
> this handled for both 1st order and 2nd order Lagrange (for
> instance)?

IIRC it's handled properly for all scalar-valued elements, where by
"properly" I mean that the derivative is returned as a directional
gradient in LIBMESH_DIM-dimensional space.  E.g. If you have an EDGE2
element with a value of 1 at the origin and 0 at the other end, then
if the other end is at (x,y,z) the gradient in physical space we
return should be (-x, -y, -z).

That means that if you're solving e.g. a Laplacian problem, then you
want to be integrating grad(u)*grad(v) as a dot product of 2 vectors,
not just assuming that you can still ignore the m>>n indexed
components for an n-dimensional element.

I'm actually not sure if anybody ever made sure we support embedded
vector-valued elements.  Cc'ing Paul Bauman; if he didn't do it then
nobody did.
---
Roy

Re: [Libmesh-users] Using multi-core in execution files

[David K. <dav...@ak...>]

This has happened to me before when I had two MPIs installed on my system
(e.g. mpich and openmpi) so that libMesh links to one during configuration
and the other is used during "mpirun".

I suggest that you make sure there is only one MPI on your system and then
rebuild libMesh and try again.

David


On Mon, Feb 12, 2018 at 9:19 PM, 강신성 <ss...@pu...> wrote:

> Thanks for your reply, David.
>
>
> I tried to the command "mpirun -np N" in the RB example 5, but there was a
> problem that the same code is running repeatedly as follows.
>
> ============================================================
> ================================
>
> $ mpirun -np 3 ./example-opt
>
> ...
>
> (skip)
>
> ...
>
>
> ---- Performing Greedy basis enrichment ----
>
>
> ---- Basis dimension: 0 ----
>
> Performing RB solves on training set
>
> Maximum error bound is 90.1602
>
>
> Performing truth solve at parameter:
>
> load_Fx: -3.274396e+00
>
> load_Fy: -4.127732e+00
>
> load_Fz: 9.887087e-01
>
> point_load_Fx: -4.856018e+00
>
> point_load_Fy: -4.622528e+00
>
> point_load_Fz: 4.774231e+00
>
> x_scaling: 1.146354e+00
>
>
>
> ---- Performing Greedy basis enrichment ----
>
>
> ---- Basis dimension: 0 ----
>
> Performing RB solves on training set
>
> Maximum error bound is 90.1602
>
>
> Performing truth solve at parameter:
>
> load_Fx: -3.274396e+00
>
> load_Fy: -4.127732e+00
>
> load_Fz: 9.887087e-01
>
> point_load_Fx: -4.856018e+00
>
> point_load_Fy: -4.622528e+00
>
> point_load_Fz: 4.774231e+00
>
> x_scaling: 1.146354e+00
>
>
>
> ---- Performing Greedy basis enrichment ----
>
>
> ---- Basis dimension: 0 ----
>
> Performing RB solves on training set
>
> Maximum error bound is 90.1602
>
>
> Performing truth solve at parameter:
>
> load_Fx: -3.274396e+00
>
> load_Fy: -4.127732e+00
>
> load_Fz: 9.887087e-01
>
> point_load_Fx: -4.856018e+00
>
> point_load_Fy: -4.622528e+00
>
> point_load_Fz: 4.774231e+00
>
> x_scaling: 1.146354e+00
>
>
> Enriching the RB space
>
> Enriching the RB space
>
> Updating RB matrices
>
> Updating RB matrices
>
> Updating RB residual terms
>
> Updating RB residual terms
>
> Enriching the RB space
>
> Updating RB matrices
>
> Updating RB residual terms
>
>
> ---- Basis dimension: 1 ----
>
> Performing RB solves on training set
>
>
> ---- Basis dimension: 1 ----
>
> Performing RB solves on training set
>
> Maximum error bound is 337.302
>
>
> Performing truth solve at parameter:
>
> load_Fx: -1.545951e-01
>
> load_Fy: -2.327825e+00
>
> load_Fz: 3.578962e+00
>
> point_load_Fx: 8.882769e-01
>
> point_load_Fy: 5.864229e-01
>
> point_load_Fz: 4.982374e+00
>
> x_scaling: 1.228777e+00
>
>
> Maximum error bound is 337.302
>
>
> Performing truth solve at parameter:
>
> load_Fx: -1.545951e-01
>
> load_Fy: -2.327825e+00
>
> load_Fz: 3.578962e+00
>
> point_load_Fx: 8.882769e-01
>
> point_load_Fy: 5.864229e-01
>
> point_load_Fz: 4.982374e+00
>
> x_scaling: 1.228777e+00
>
>
>
> ---- Basis dimension: 1 ----
>
> Performing RB solves on training set
>
> Maximum error bound is 337.302
>
>
> Performing truth solve at parameter:
>
> load_Fx: -1.545951e-01
>
> load_Fy: -2.327825e+00
>
> load_Fz: 3.578962e+00
>
> point_load_Fx: 8.882769e-01
>
> point_load_Fy: 5.864229e-01
>
> point_load_Fz: 4.982374e+00
>
> x_scaling: 1.228777e+00
>
>
> Enriching the RB space
>
> Updating RB matrices
>
> Enriching the RB space
>
> Updating RB matrices
>
> Updating RB residual terms
>
> Updating RB residual terms
>
> Enriching the RB space
>
> Updating RB matrices
>
> Updating RB residual terms
>
>
> ---- Basis dimension: 2 ----
>
> Performing RB solves on training set
>
>
> ---- Basis dimension: 2 ----
>
> Performing RB solves on training set
>
> Maximum error bound is 469.21
>
>
> ...
>
> (skip)
>
> ...
>
>
> ---- Basis dimension: 15 ----
>
> Performing RB solves on training set
>
>
> ---- Basis dimension: 15 ----
>
> Performing RB solves on training set
>
>
> ---- Basis dimension: 15 ----
>
> Performing RB solves on training set
>
> Maximum error bound is 2.50754
>
>
> Maximum number of basis functions reached: Nmax = 15
>
> *** Warning, This code is deprecated, and likely to be removed in future
> library versions! ./include/libmesh/mesh_tools.h, line 70, compiled Aug
> 25 2017 at 02:15:21 ***
>
> Maximum error bound is 2.50754
>
>
> Maximum number of basis functions reached: Nmax = 15
>
> *** Warning, This code is deprecated, and likely to be removed in future
> library versions! ./include/libmesh/mesh_tools.h, line 70, compiled Aug
> 25 2017 at 02:15:21 ***
>
> Maximum error bound is 2.50754
>
>
> Maximum number of basis functions reached: Nmax = 15
>
> *** Warning, This code is deprecated, and likely to be removed in future
> library versions! ./include/libmesh/mesh_tools.h, line 70, compiled Aug
> 25 2017 at 02:15:21 ***
>
> (end)
>
> ============================================================
> ============================================================
> ============================
>
> Other examples had the same problem, too.
>
> Did I type the command wrong? If not, I want to know what is wrong.
>
>
> Best regards,
>
> Kang
>
>
>
>
>
>
>
> *----- Original Message -----From: David Knezevic
> <dav...@ak... <dav...@ak...>>To: "S. Kang"
> <ss...@pu... <ss...@pu...>>Cc: Libmesh user group
> <lib...@li...
> <lib...@li...>>Date: Mon, 12 Feb 2018 22:28:09 +0900
> (GMT)subject: Re: [Libmesh-users] Using multi-core in execution files*
>
>
> Hello,
>
> You can run the reduced basis code in parallel. You do it just the same
> way that you run any other libMesh code in parallel, i.e. just run with
> "mpirun -np N" where N specifies the number of processors that you want to
> use.
>
> If you want more info on the parallelization approach that is used, please
> refer to this paper
> <https://www.sciencedirect.com/science/article/pii/S0045782510003828>.
>
> Best,
> David
>
>
> On Sun, Feb 11, 2018 at 9:30 PM, S. Kang <ss...@pu...> wrote:
>
>>
>>
>>
>>   Hello everyone,
>>
>>
>>
>>   I am solving RB problems, but it takes too long because of many basis
>> vectors.
>>   So, similar to "make -j 10", I want to know how to use multi-core in
>> execution files, not parallel programming.
>>
>>
>>   Best regards,
>>
>>   S. Kang.
>>
>>
>>
>> ------------------------------ ------------------------------
>> Shinseong Kang
>> Graduate Student
>> Pusan National University, South Korea
>> H.P.: 010-9770-6595
>> E-mail: ss...@pu...
>> ------------------------------ ------------------------------
>> ------------------------------ ------------------------------
>> ------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> ______________________________ _________________
>> Libmesh-users mailing list
>> Lib...@li...
>> https://lists.sourceforge.net/lists/listinfo/libmesh-users
>>
>
>
>

Re: [Libmesh-users] Using multi-core in execution files

[강신성 <ss...@pu...>]

 
  
  Thanks for your reply, David. 
  
 
  I tried to the command "mpirun -np N" in the RB example 5, but there was a problem that the same code is running repeatedly as follows. 
  ============================================================================================ 
  $ mpirun -np 3 ./example-opt 
  ... 
  (skip) 
  ... 
  
 
  ---- Performing Greedy basis enrichment ---- 
  
 
  ---- Basis dimension: 0 ---- 
  Performing RB solves on training set 
  Maximum error bound is 90.1602 
  
 
  Performing truth solve at parameter: 
  load_Fx: -3.274396e+00 
  load_Fy: -4.127732e+00 
  load_Fz: 9.887087e-01 
  point_load_Fx: -4.856018e+00 
  point_load_Fy: -4.622528e+00 
  point_load_Fz: 4.774231e+00 
  x_scaling: 1.146354e+00 
  
 
  
 
  ---- Performing Greedy basis enrichment ---- 
  
 
  ---- Basis dimension: 0 ---- 
  Performing RB solves on training set 
  Maximum error bound is 90.1602 
  
 
  Performing truth solve at parameter: 
  load_Fx: -3.274396e+00 
  load_Fy: -4.127732e+00 
  load_Fz: 9.887087e-01 
  point_load_Fx: -4.856018e+00 
  point_load_Fy: -4.622528e+00 
  point_load_Fz: 4.774231e+00 
  x_scaling: 1.146354e+00 
  
 
  
 
  ---- Performing Greedy basis enrichment ---- 
  
 
  ---- Basis dimension: 0 ---- 
  Performing RB solves on training set 
  Maximum error bound is 90.1602 
  
 
  Performing truth solve at parameter: 
  load_Fx: -3.274396e+00 
  load_Fy: -4.127732e+00 
  load_Fz: 9.887087e-01 
  point_load_Fx: -4.856018e+00 
  point_load_Fy: -4.622528e+00 
  point_load_Fz: 4.774231e+00 
  x_scaling: 1.146354e+00 
  
 
  Enriching the RB space 
  Enriching the RB space 
  Updating RB matrices 
  Updating RB matrices 
  Updating RB residual terms 
  Updating RB residual terms 
  Enriching the RB space 
  Updating RB matrices 
  Updating RB residual terms 
  
 
  ---- Basis dimension: 1 ---- 
  Performing RB solves on training set 
  
 
  ---- Basis dimension: 1 ---- 
  Performing RB solves on training set 
  Maximum error bound is 337.302 
  
 
  Performing truth solve at parameter: 
  load_Fx: -1.545951e-01 
  load_Fy: -2.327825e+00 
  load_Fz: 3.578962e+00 
  point_load_Fx: 8.882769e-01 
  point_load_Fy: 5.864229e-01 
  point_load_Fz: 4.982374e+00 
  x_scaling: 1.228777e+00 
  
 
  Maximum error bound is 337.302 
  
 
  Performing truth solve at parameter: 
  load_Fx: -1.545951e-01 
  load_Fy: -2.327825e+00 
  load_Fz: 3.578962e+00 
  point_load_Fx: 8.882769e-01 
  point_load_Fy: 5.864229e-01 
  point_load_Fz: 4.982374e+00 
  x_scaling: 1.228777e+00 
  
 
  
 
  ---- Basis dimension: 1 ---- 
  Performing RB solves on training set 
  Maximum error bound is 337.302 
  
 
  Performing truth solve at parameter: 
  load_Fx: -1.545951e-01 
  load_Fy: -2.327825e+00 
  load_Fz: 3.578962e+00 
  point_load_Fx: 8.882769e-01 
  point_load_Fy: 5.864229e-01 
  point_load_Fz: 4.982374e+00 
  x_scaling: 1.228777e+00 
  
 
  Enriching the RB space 
  Updating RB matrices 
  Enriching the RB space 
  Updating RB matrices 
  Updating RB residual terms 
  Updating RB residual terms 
  Enriching the RB space 
  Updating RB matrices 
  Updating RB residual terms 
  
 
  ---- Basis dimension: 2 ---- 
  Performing RB solves on training set 
  
 
  ---- Basis dimension: 2 ---- 
  Performing RB solves on training set 
  Maximum error bound is 469.21 
  
 
   
   ... 
   (skip) 
   ... 
  
 
  
 
  ---- Basis dimension: 15 ---- 
  Performing RB solves on training set 
  
 
  ---- Basis dimension: 15 ---- 
  Performing RB solves on training set 
  
 
  ---- Basis dimension: 15 ---- 
  Performing RB solves on training set 
  Maximum error bound is 2.50754 
  
 
  Maximum number of basis functions reached: Nmax = 15 
  *** Warning, This code is deprecated, and likely to be removed in future library versions! ./include/libmesh/mesh_tools.h, line 70, compiled Aug 25 2017 at 02:15:21 *** 
  Maximum error bound is 2.50754 
  
 
  Maximum number of basis functions reached: Nmax = 15 
  *** Warning, This code is deprecated, and likely to be removed in future library versions! ./include/libmesh/mesh_tools.h, line 70, compiled Aug 25 2017 at 02:15:21 *** 
  Maximum error bound is 2.50754 
  
 
  Maximum number of basis functions reached: Nmax = 15 
  *** Warning, This code is deprecated, and likely to be removed in future library versions! ./include/libmesh/mesh_tools.h, line 70, compiled Aug 25 2017 at 02:15:21 *** 
   
   
 
  
 
  
    (end) 
  
 
   
  ==================================================================================================================================================== 
  Other examples had the same problem, too. 
  Did I type the command wrong? If not, I want to know what is wrong. 
  
 
  Best regards, 
  Kang 
  
 
   
   ----- Original Message -----
From: David Knezevic <dav...@ak...>
To: "S. Kang" <ss...@pu...>
Cc: Libmesh user group <lib...@li...>
Date: Mon, 12 Feb 2018 22:28:09 +0900 (GMT)
subject: Re: [Libmesh-users] Using multi-core in execution files 
   
 
   
     Hello, 
     
     
 
    
 
    
      You can run the reduced basis code in parallel. You do it just the same way that you run any other libMesh code in parallel, i.e. just run with "mpirun -np N" where N specifies the number of processors that you want to use. 
    
 
     
     
 
    
 
    
      If you want more info on the parallelization approach that is used, please refer to 
     this paper. 
    
 
     
     
 
    
 
    
      Best, 
    
 
    
      David 
    
 
     
     
 
    
 
     
     
 
     
       On Sun, Feb 11, 2018 at 9:30 PM, S. Kang 
      <ss...@pu...> wrote: 
      
 
       
       
 
       
 
       
   Hello everyone, 
       
 
       
 
       
 
       
   I am solving RB problems, but it takes too long because of many basis vectors. 
       
   So, similar to "make -j 10", I want to know how to use multi-core in execution files, not parallel programming. 
       
 
       
 
       
   Best regards, 
       
 
       
   S. Kang. 
       
 
       
 
       
 
       
 ------------------------------ 
       ------------------------------ 
       
 Shinseong Kang 
       
 Graduate Student 
       
 Pusan National University, South Korea 
       
 H.P.: 010-9770-6595 
       
 E-mail: 
       ss...@pu... 
       
 ------------------------------ 
       ------------------------------ 
       
 ------------------------------ 
       ------------------------------ 
       ------------------ 
       
 Check out the vibrant tech community on one of the world's most 
       
 engaging tech sites, Slashdot.org! 
       http://sdm.link/slashdot 
       
 ______________________________ 
       _________________ 
       
 Libmesh-users mailing list 
       
 
       Lib...@li... 
       
 
       https://lists.sourceforge.net/lists/listinfo/libmesh-users 
       
 
       
     
 
     
 
    
 
   
 
   
  
 
 

Re: [Libmesh-users] Is LIBS treated correctly?

[John P. <jwp...@gm...>]

On Mon, Feb 12, 2018 at 12:43 PM, Victor Eijkhout <eij...@ta...>
wrote:

> I’m attaching a configure log file. I put a python library in the LIBS
> variable, and it is found and validated, but then not added to the optional
> libraries. This means that during linking I get an error from pytrilinos
> which can not find the python library.
>

It doesn't look like we do anything with $LIBS during configure, other than
to use it for test linking.

As a short term workaround, you could try putting your custom library+path
in the $libmesh_LDFLAGS environment variable, as I think we actually
respect the value of that one.

I think to be consistent with libmesh_LDFLAGS and libmesh_CXXFLAGS, we
would probably end up reading the value of libmesh_LIBS from the
environment. This is definitely non-standard, but I think the thinking was
to avoid accidentally picking up LDFLAGS/CXXFLAGS/LIBS from the user's
environment that they may have set for other reasons...

-- 
John

Re: [Libmesh-users] 1D/2D elements in 3D space

[Manav B. <bha...@gm...>]

Thanks! 

So, would the shape function derivatives account the orientation of the element? 

For instance, a 1D element oriented along:   x-axis   vs   y-axis   vs   x=y line. 

In all cases, there is only one shape function defined along the element coordinate. But its derivative wrt x and y will vary. Is this handled for both 1st order and 2nd order Lagrange (for instance)?

-Manav

> On Feb 12, 2018, at 5:06 PM, Roy Stogner <roy...@ic...> wrote:
> 
> 
> On Mon, 12 Feb 2018, Manav Bhatia wrote:
> 
>>  I was looking through some code in FE and noticed some comments
>>  about 1D/2D elements in 3D space. What is the extent of support
>>  for this?
> 
> IIRC:
> 
> If you're using just one or just the other, then the support should be
> complete.
> 
> If you're connecting one to the other (or connecting either/both to 3D
> elements), then you don't get neighbor links for those connections.
> 
> If you're overlapping one on or within the other (e.g. elements which
> occupy the sides of higher dimensional elements) and you want them to
> share DoFs consistently then I think you're limited to LAGRANGE
> variables for those DoFs.
> ---
> Roy

Re: [Libmesh-users] 1D/2D elements in 3D space

[Roy S. <roy...@ic...>]

On Mon, 12 Feb 2018, Manav Bhatia wrote:

>   I was looking through some code in FE and noticed some comments
>   about 1D/2D elements in 3D space. What is the extent of support
>   for this?

IIRC:

If you're using just one or just the other, then the support should be
complete.

If you're connecting one to the other (or connecting either/both to 3D
elements), then you don't get neighbor links for those connections.

If you're overlapping one on or within the other (e.g. elements which
occupy the sides of higher dimensional elements) and you want them to
share DoFs consistently then I think you're limited to LAGRANGE
variables for those DoFs.
---
Roy