libmesh-users — General information for libmesh users

[Libmesh-users] L2 Projection between meshes with split dofs

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

Hi all,

I have a doubt on L2 projection between meshes with split dofs.

I am currently using the following code to project values from one mesh to
another more refined one (I perform refinement myself):

      MeshFunction * mesh_func = new MeshFunction( . . . );
      mesh_func->init();
      mesh_func->enable_out_of_mesh_mode( 0 );
      sys.project_solution( ... )

I can see it interpolates the projected values based on the coordinate of
the dofs. Is that so?

It happens that in some coordinates I have duplicated dofs representing
fractures. Displacements are different on both sides of the fracture even
though their coordinates are the same.
Can you see any smart-hack to avoid the interpolation _only_ on fracture
nodes?
Or should I rewrite the whole 'project_solution' with my own stuff?

Thanks,
Renato

Re: [Libmesh-users] question about libmesh without MPI

[Stogner, R. H <roy...@ic...>]

On Wed, 20 Nov 2019, Stogner, Roy H wrote:

> On Tue, 19 Nov 2019, Povolotskyi, Mykhailo wrote:
>
>> I can build petsc with -with-mpi=0
>>
>> Then I configured libmesh with --enable_petsc.
>>
>> Libmesh took mpiuni implementation  from PETSc.
>>
>> 1.4.1 was compiled okay, and my application works fine.
>>
>> 1.5.0 had compilation errors, I could not built in.
>
> Let me know the details?  I'll try it myself now and see what happens
> for me.

I see one bit of breakage and a few warnings; they're fixed in
https://github.com/libMesh/libmesh/pull/2346

I've also cherry-picked them onto a v1.5.1_branch - I don't know when
we'll want to tag and release that but you could use the branch now if
you want something that's got the fixes but is newer than 1.4.1 and
safer than the current git master.
---
Roy

Re: [Libmesh-users] question about libmesh without MPI

[Stogner, R. H <roy...@ic...>]

On Tue, 19 Nov 2019, Povolotskyi, Mykhailo wrote:

> I can build petsc with -with-mpi=0
>
> Then I configured libmesh with --enable_petsc.
>
> Libmesh took mpiuni implementation  from PETSc.
>
> 1.4.1 was compiled okay, and my application works fine.
>
> 1.5.0 had compilation errors, I could not built in.

Let me know the details?  I'll try it myself now and see what happens
for me.
---
Roy

Re: [Libmesh-users] question about libmesh without MPI

[Povolotskyi, M. <mpo...@pu...>]

Here is what I found.

I can build petsc with -with-mpi=0

Then I configured libmesh with --enable_petsc.

Libmesh took mpiuni implementation  from PETSc.

1.4.1 was compiled okay, and my application works fine.

1.5.0 had compilation errors, I could not built in.

On 11/19/2019 6:05 PM, Stogner, Roy H wrote:
> On Tue, 19 Nov 2019, Povolotskyi, Mykhailo wrote:
>
>> is it possible to build petsc without MPI and configure libmesh with
>> --enable_petsc and --disable_mpi?
> In theory, yes.
>
> In practice, I don't think that configuration is still in CI, so it
> wouldn't surprise me if 1.5.0 or master or both were broken in that
> case.  If you run into any problems, please let us know!
> ---
> Roy

Re: [Libmesh-users] question about libmesh without MPI

[Stogner, R. H <roy...@ic...>]

On Tue, 19 Nov 2019, Povolotskyi, Mykhailo wrote:

> is it possible to build petsc without MPI and configure libmesh with
> --enable_petsc and --disable_mpi?

In theory, yes.

In practice, I don't think that configuration is still in CI, so it
wouldn't surprise me if 1.5.0 or master or both were broken in that
case.  If you run into any problems, please let us know!
---
Roy

[Libmesh-users] question about libmesh without MPI

[Povolotskyi, M. <mpo...@pu...>]

Hello,

is it possible to build petsc without MPI and configure libmesh with 
--enable_petsc and --disable_mpi?

Thank you,

Michael.

Re: [Libmesh-users] FEClough periodic BC

[gmail <a.m...@gm...>]

Hi,

> On Nov 6, 2019, at 12:27 PM, Stogner, Roy H <roy...@ic...> wrote:
> 
> 
> On Wed, 6 Nov 2019, gmail wrote:
> 
>> I noticed that periodic BC does not work for FEClough. I see the
>> functions for it but I’m guessing it was never implemented.
> 
> Could you be more specific?
> FEGenericBase::compute_periodic_constraints is supposed to work for
> every scalar-valued FE type.

I’m doing a nonlinear mixed laplacian and bilaplacian with PetscDM. 

My energy is something like:

E=\int \left(w(\phi)+A(\nabla\phi/|\nabla\phi)^2 \xi^2 |\nabla\phi|^2 +\beta\xi^4 |\nabla^2\phi|^2 \right) dx			(1)

where w is a polynomial and A is a messy scalar function of vector the normal to \phi (\nabla\phi/|\nabla\phi).

I’m trying to solve the nonlinear Euler-Lagrange

\partial E/\partial \phi (\tilde{\phi})=0 	\forall\tilde{\phi}															(2)

The natural boundary condition of this gives some messy flux on the boundary = 0.

No when I try to solve (2) with \phi interpolated with FEClough, if I enforce periodicity it does not work and gives me exactly the same solution as though the periodic boundary is not there.

When I do the same with \beta\equiv0 and solve (2) with FELagrange and periodic it works perfectly as expected.

> 
>> My question is wether periodic BCs do work for FEHermite or is there
>> a reason why the current implementation would not work for C1
>> basses.
> 
> We combine Hermite bases with periodic BCs in miscellaneous ex7,
> though I don't think we have good enough assertion coverage of the
> results for me to swear there's been no regressions, especially if
> you're correct and something's no longer working with the
> Clough-Tocher basis.

Thanks. I guess to reproduce the error, I can try to replace Hermite with Clough-Tocher and see if this gives the same output!

> ---
> Roy

Re: [Libmesh-users] FEClough periodic BC

[Stogner, R. H <roy...@ic...>]

On Wed, 6 Nov 2019, gmail wrote:

> I noticed that periodic BC does not work for FEClough. I see the
> functions for it but I’m guessing it was never implemented.

Could you be more specific?
FEGenericBase::compute_periodic_constraints is supposed to work for
every scalar-valued FE type.

> My question is wether periodic BCs do work for FEHermite or is there
> a reason why the current implementation would not work for C1
> basses.

We combine Hermite bases with periodic BCs in miscellaneous ex7,
though I don't think we have good enough assertion coverage of the
results for me to swear there's been no regressions, especially if
you're correct and something's no longer working with the
Clough-Tocher basis.
---
Roy

[Libmesh-users] FEClough periodic BC

[gmail <a.m...@gm...>]

Hi,

I noticed that periodic BC does not work for FEClough. I see the functions for it but I’m guessing it was never implemented. My question is wether periodic BCs do work for FEHermite or is there a reason why the current implementation would not work for C1 basses.

Thanks as always,
Ata

Re: [Libmesh-users] Cannot read ABAQUS .inp file with *Surface

[Yuxiang W. <yw...@vi...>]

Created ticket 2315:  https://github.com/libMesh/libmesh/issues/2315
And submitted PR 2316: https://github.com/libMesh/libmesh/pull/2316

On Wed, Oct 30, 2019 at 2:48 PM Yuxiang Wang <yw...@vi...> wrote:

> Thank you John for looking at it! I have been reading abaqus_io.C and
> think I found out why.
>
> There are two ways for ABAQUS to define the surface and only #1 is
> supported by libMesh now:
> 1) By specifying elem_id, side_id. This is the currently supported one,
> for example "391, S2"
> 2) By specifying elemset_name, side_id. This is NOT currently supported,
> and looks like "Elset_1, S3". This will probably be internally expanded to
> the format like #1: it will find all the elem_ids in the element set of
> Elset_1, and use S3 for all of them.
>
> We added a few lines and this now works with the #2 as well. Should I
> create a ticket and a pull request?
>
> Best,
> Shawn
>
> On Wed, Oct 30, 2019 at 6:07 AM John Peterson <jwp...@gm...>
> wrote:
>
>> Hi Yuxiang,
>>
>> I will try and take a look at this when I get a chance... it's likely
>> that there is a bug in our Abaqus reader. There is a certain amount of
>> variation allowed in the formatting of Abaqus files, and we may not support
>> exactly the format you are using.
>>
>> --
>> John
>>
>>
>> On Tue, Oct 29, 2019 at 3:26 PM Yuxiang Wang <yw...@vi...> wrote:
>>
>>> Dear all,
>>>
>>> I noticed that whenever I have *Surface in the ABAQUS .inp file, libmesh
>>> cannot read it. I thought this was implemented according to here:
>>>
>>> https://libmesh.github.io/doxygen/classlibMesh_1_1AbaqusIO.html#a2a125c1845edc4c3a6fad266fc76cbfd
>>>
>>>
>>> I have a very short dummy mesh (9 nodes in a unit cube) and a short
>>> libmesh
>>> C++ codethat I tested with (attached). whenever I run this with the
>>> example
>>> file, it says:
>>>
>>> Stream is bad! Perhaps the file: testcube.inp does not exist?
>>>
>>> Could anyone please help comment?
>>>
>>> Best,
>>> Shawn
>>>
>>
>>
>
> --
> Yuxiang "Shawn" Wang, PhD
> yw...@vi...
> +1 (434) 284-0836
>


-- 
Yuxiang "Shawn" Wang, PhD
yw...@vi...
+1 (434) 284-0836

Re: [Libmesh-users] Cannot read ABAQUS .inp file with *Surface

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

On Wed, Oct 30, 2019 at 4:48 PM Yuxiang Wang <yw...@vi...> wrote:

> Thank you John for looking at it! I have been reading abaqus_io.C and
> think I found out why.
>
> There are two ways for ABAQUS to define the surface and only #1 is
> supported by libMesh now:
> 1) By specifying elem_id, side_id. This is the currently supported one,
> for example "391, S2"
> 2) By specifying elemset_name, side_id. This is NOT currently supported,
> and looks like "Elset_1, S3". This will probably be internally expanded to
> the format like #1: it will find all the elem_ids in the element set of
> Elset_1, and use S3 for all of them.
>
> We added a few lines and this now works with the #2 as well. Should I
> create a ticket and a pull request?
>

Sure, that would be great.

Thanks,
John

Re: [Libmesh-users] Cannot read ABAQUS .inp file with *Surface

[Yuxiang W. <yw...@vi...>]

Thank you John for looking at it! I have been reading abaqus_io.C and think
I found out why.

There are two ways for ABAQUS to define the surface and only #1 is
supported by libMesh now:
1) By specifying elem_id, side_id. This is the currently supported one, for
example "391, S2"
2) By specifying elemset_name, side_id. This is NOT currently supported,
and looks like "Elset_1, S3". This will probably be internally expanded to
the format like #1: it will find all the elem_ids in the element set of
Elset_1, and use S3 for all of them.

We added a few lines and this now works with the #2 as well. Should I
create a ticket and a pull request?

Best,
Shawn

On Wed, Oct 30, 2019 at 6:07 AM John Peterson <jwp...@gm...> wrote:

> Hi Yuxiang,
>
> I will try and take a look at this when I get a chance... it's likely that
> there is a bug in our Abaqus reader. There is a certain amount of variation
> allowed in the formatting of Abaqus files, and we may not support exactly
> the format you are using.
>
> --
> John
>
>
> On Tue, Oct 29, 2019 at 3:26 PM Yuxiang Wang <yw...@vi...> wrote:
>
>> Dear all,
>>
>> I noticed that whenever I have *Surface in the ABAQUS .inp file, libmesh
>> cannot read it. I thought this was implemented according to here:
>>
>> https://libmesh.github.io/doxygen/classlibMesh_1_1AbaqusIO.html#a2a125c1845edc4c3a6fad266fc76cbfd
>>
>>
>> I have a very short dummy mesh (9 nodes in a unit cube) and a short
>> libmesh
>> C++ codethat I tested with (attached). whenever I run this with the
>> example
>> file, it says:
>>
>> Stream is bad! Perhaps the file: testcube.inp does not exist?
>>
>> Could anyone please help comment?
>>
>> Best,
>> Shawn
>>
>
>

-- 
Yuxiang "Shawn" Wang, PhD
yw...@vi...
+1 (434) 284-0836

Re: [Libmesh-users] Cannot read ABAQUS .inp file with *Surface

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

Hi Yuxiang,

I will try and take a look at this when I get a chance... it's likely that
there is a bug in our Abaqus reader. There is a certain amount of variation
allowed in the formatting of Abaqus files, and we may not support exactly
the format you are using.

--
John


On Tue, Oct 29, 2019 at 3:26 PM Yuxiang Wang <yw...@vi...> wrote:

> Dear all,
>
> I noticed that whenever I have *Surface in the ABAQUS .inp file, libmesh
> cannot read it. I thought this was implemented according to here:
>
> https://libmesh.github.io/doxygen/classlibMesh_1_1AbaqusIO.html#a2a125c1845edc4c3a6fad266fc76cbfd
>
>
> I have a very short dummy mesh (9 nodes in a unit cube) and a short libmesh
> C++ codethat I tested with (attached). whenever I run this with the example
> file, it says:
>
> Stream is bad! Perhaps the file: testcube.inp does not exist?
>
> Could anyone please help comment?
>
> Best,
> Shawn
>

[Libmesh-users] Cannot read ABAQUS .inp file with *Surface

[Yuxiang W. <yw...@vi...>]

Dear all,

I noticed that whenever I have *Surface in the ABAQUS .inp file, libmesh
cannot read it. I thought this was implemented according to here:
https://libmesh.github.io/doxygen/classlibMesh_1_1AbaqusIO.html#a2a125c1845edc4c3a6fad266fc76cbfd


I have a very short dummy mesh (9 nodes in a unit cube) and a short libmesh
C++ codethat I tested with (attached). whenever I run this with the example
file, it says:

Stream is bad! Perhaps the file: testcube.inp does not exist?

Could anyone please help comment?

Best,
Shawn


-- 
Yuxiang "Shawn" Wang, PhD
yw...@vi...
+1 (434) 284-0836

Re: [Libmesh-users] Don't prolong/restrict some system vectors

[Alexander L. <ale...@gm...>]

Yes, I think that's the best solution. Thanks Roy

On Fri, Oct 18, 2019 at 2:30 PM Stogner, Roy H <roy...@ic...>
wrote:

>
> On Fri, 18 Oct 2019, Alexander Lindsay wrote:
>
> > Is there a way to prevent prolongation/restriction of some System vectors
> > during mesh adaptation?  I see the *preserve* APIs but that doesn't look
> > like it does what I would want.... Basically I am performing grid
> > sequencing, obtaining initial guesses for fine grids based on solutions
> of
> > coarse grids. In a transient problem I have an old solution vector for
> > calculating time derivatives. Restricting this vector for the initial
> > coarse grid solution and then prolonging it for the fine grid solution
> > loses the fine detail from the previous time step.
>
> I don't think we've got anything like that.  Part of having a vector
> attached to a System is having the system take care of making sure it
> matches the system DoF partitioning.  The way to keep a vector that's
> *that* independent of a System is to not add it to the System in the
> first place.  Can you either allocate your vector separately, or
> instead temporarily clone it and save the clone through your
> coarsen/refine cycle?
> ---
> Roy
>

Re: [Libmesh-users] Don't prolong/restrict some system vectors

[Stogner, R. H <roy...@ic...>]

On Fri, 18 Oct 2019, Alexander Lindsay wrote:

> Is there a way to prevent prolongation/restriction of some System vectors
> during mesh adaptation?  I see the *preserve* APIs but that doesn't look
> like it does what I would want.... Basically I am performing grid
> sequencing, obtaining initial guesses for fine grids based on solutions of
> coarse grids. In a transient problem I have an old solution vector for
> calculating time derivatives. Restricting this vector for the initial
> coarse grid solution and then prolonging it for the fine grid solution
> loses the fine detail from the previous time step.

I don't think we've got anything like that.  Part of having a vector
attached to a System is having the system take care of making sure it
matches the system DoF partitioning.  The way to keep a vector that's
*that* independent of a System is to not add it to the System in the
first place.  Can you either allocate your vector separately, or
instead temporarily clone it and save the clone through your
coarsen/refine cycle?
---
Roy

[Libmesh-users] Don't prolong/restrict some system vectors

[Alexander L. <ale...@gm...>]

Is there a way to prevent prolongation/restriction of some System vectors
during mesh adaptation?  I see the *preserve* APIs but that doesn't look
like it does what I would want.... Basically I am performing grid
sequencing, obtaining initial guesses for fine grids based on solutions of
coarse grids. In a transient problem I have an old solution vector for
calculating time derivatives. Restricting this vector for the initial
coarse grid solution and then prolonging it for the fine grid solution
loses the fine detail from the previous time step.

Alex

[Libmesh-users] AMD HIP Tutorial at SC19

[Paul T. B. <ptb...@gm...>]

(Apologies if you receive multiple copies of this announcement.)

My group at AMD will be presenting tutorials on the HIP programming
language during SC19 in Denver, CO. HIP is AMD's GPU programming language,
very similar to CUDA.

Please see the following link below for the official advertisement (sorry
for the link, the ad is ~1MB pdf).
https://drive.google.com/open?id=1to5zo7QtsfClI98FXV3h9bGiKHF8eksu

If you have questions, feel free to contact me at pau...@am....
Otherwise, please use the point-of-contact in the ad if you'd like to
reserve a spot at one of the tutorials.

Hope to see you folks in Denver.

Thanks,

Paul

[Libmesh-users] [RE]Re: [RE]Re: [RB] Assembly for a Interior (neighbor) side between elements

[Shinseong K. <ss...@pu...>]

I understood your advise.I seem to have modified thefile again this time because I have often modified "RB_construction.C"to printoutput error bounds during an offline stage.Thank you for reminding me of a better way.Best regards,Kang------------------------------------------------------------
ShinseongKang
GraduateStudent
PusanNationalUniversity, South KoreaTel.: +82-051-510-3052
H.P.:+82-010-9770-6595
E-mail:ss...@pu...

----------------------------------------------------------------- Original Message -----From : David Knezevic <dav...@ak...>To : "Shinseong Kang" <ss...@pu...>Cc : "Libmesh user group" <lib...@li...>Sent : 2019-10-10 10:15:15Subject : Re: [RE]Re: [RB] Assembly for a Interior (neighbor) side between elementsAs youadvised, I edited that part in "RB_construction.C" and ranmy code again.As a result, I could obtain the correct result.OK, good to hear! By the way, I didn't mean that you need to edit rb_construction.C. Theimpose_internal_fluxes boolean is a public member of the RBConstruction class, so you can just set 

impose_internal_fluxes 

to true in the RBConstruction object that you're using. You can do that in your application code, no need to edit the libMesh library code.Best,David----- Original Message -----From : David Knezevic <dav...@ak...>To : "Shinseong Kang" <ss...@pu...>Cc : "Libmesh user group" <lib...@li...>Sent : 2019-10-08 21:53:36Subject : Re: [RB] Assembly for a Interior (neighbor) side between elementsHello,I think your approach is basically correct, butissue is that by default the code skips assembly on internal sides for the sake of efficiency (since usually we do not need to do assembly on internal sides). In order to not skip internal sides you can set "impose_internal_fluxes = true" on your RBConstruction object. That is false by default and if you look atRBConstruction::add_scaled_matrix_and_vector() you will see that you have to set it to true in order to loop over non-boundary sides.Let me know if that works for you.Best,DavidOn Tue, Oct 8, 2019 at 6:57 AM Shinseong Kang <ss...@pu...> wrote:Hello, all.I triedto definean output in a simply supported 3-D beam problem.My output is an average displacement in the middle of the beam.For simplicity, I only used two brick elements, i.e, ■|■, where"■" is an element, and"|" is a location I want to compute the average output.To do this, I utilized the codes in RB example 5.First, Ideclared "ThetaOutput" (parameter-dependent term) and alsodeclared "AssemblyOutput" (parameter-independent term) as follows:=======================================voidAssemblyOutput::boundary_assembly(FEMContext & c)}=======================================As you can see, The above code is very similar to"Assemblyp1" in "assembly.C" ofRB example 5.However, I could not obtain the correct output because the above code cannot deal with interior side between elements.In other words, theboundary information of FEMContext only include outer side.I tried to find another way, but I could not find the right solution.Therefore,I'd like your help.To summarize my questions areas follows:1. Is there any way to assemble an interior (neighbor) sidebetween elements?2. How to compute anaverage displacement for the middleof a beam in terms of the RB codes?Thank you.Best regards,Kang------------------------------------------------------------
ShinseongKang
GraduateStudent
PusanNationalUniversity, South KoreaTel.: +82-051-510-3052
H.P.:+82-010-9770-6595
E-mail:ss...@pu...

------------------------------------------------------------

Re: [Libmesh-users] [RE]Re: [RB] Assembly for a Interior (neighbor) side between elements

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

>
> As you advised, I edited that part in "RB_construction.C" and ran my code
> again.
>
> As a result, I could obtain the correct result.
>

OK, good to hear! By the way, I didn't mean that you need to edit
rb_construction.C. The impose_internal_fluxes boolean is a public member of
the RBConstruction class, so you can just set impose_internal_fluxes to
true in the RBConstruction object that you're using. You can do that in
your application code, no need to edit the libMesh library code.

Best,
David



> ----- Original Message -----
> From : David Knezevic <dav...@ak...>
> To : "Shinseong Kang" <ss...@pu...>
> Cc : "Libmesh user group" <lib...@li...>
> Sent : 2019-10-08 21:53:36
> Subject : Re: [RB] Assembly for a Interior (neighbor) side between elements
>
>
> Hello,
>
> I think your approach is basically correct, but issue is that by default
> the code skips assembly on internal sides for the sake of efficiency (since
> usually we do not need to do assembly on internal sides). In order to not
> skip internal sides you can set "impose_internal_fluxes = true" on your
> RBConstruction object. That is false by default and if you look
> at RBConstruction::add_scaled_matrix_and_vector() you will see that you
> have to set it to true in order to loop over non-boundary sides.
>
> Let me know if that works for you.
>
> Best,
> David
>
> On Tue, Oct 8, 2019 at 6:57 AM Shinseong Kang <ss...@pu...> wrote:
>
>> Hello, all.
>>
>>
>>
>> I tried to define an output in a simply supported 3-D beam problem.
>>
>> My output is an average displacement in the middle of the beam.
>>
>> For simplicity, I only used two brick elements, i.e, ■|■, where "■" is
>> an element, and "|" is a location I want to compute the average output.
>>
>>
>> To do this, I utilized the codes in RB example 5.
>>
>> First, I declared "ThetaOutput" (parameter-dependent term) and
>> also declared "AssemblyOutput" (parameter-independent term) as follows:
>>
>> =======================================
>>
>> void  AssemblyOutput::boundary_assembly(FEMContext & c)
>>
>> {
>>
>>   if (rb_sys.get_mesh().get_boundary_info().has_boundary_id
>>
>>       (&c.get_elem(), c.side, BOUNDARY_ID_MID))
>>
>>     {
>>
>>       const unsigned int u_var = 0;
>>
>>       const unsigned int v_var = 1;
>>
>>
>>       FEBase * side_fe = libmesh_nullptr;
>>
>>       c.get_side_fe(v_var, side_fe);
>>
>>
>>       const std::vector<Real> & JxW_side = side_fe->get_JxW();
>>
>>
>>       const std::vector<std::vector<Real> > & phi_side =
>> side_fe->get_phi();
>>
>>
>>       const unsigned int n_v_dofs = c.get_dof_indices(v_var).size();
>>
>>
>>       unsigned int n_qpoints = c.get_side_qrule().n_points();
>>
>>       DenseSubVector<Number> & output = c.get_elem_residual(v_var);
>>
>>
>>       for (unsigned int qp=0; qp < n_qpoints; qp++)
>>
>>         for (unsigned int i=0; i < n_v_dofs; i++)
>>
>>           output(i) += JxW_side[qp] * (1. * phi_side[i][qp]);
>>
>>     }
>>
>> }
>>
>> =======================================
>> As you can see, The above code is very similar to "Assemblyp1" in
>> "assembly.C" of RB example 5.
>>
>> However, I could not obtain the correct output because the above code
>> cannot deal with interior side between elements.
>> In other words, the boundary information of FEMContext only include outer
>> side.
>>
>> I tried to find another way, but I could not find the right solution.
>> Therefore, I'd like your help.
>>
>> To summarize my questions are as follows:
>> 1. Is there any way to assemble an interior (neighbor) side between
>> elements?
>> 2. How to compute an average displacement for the middle of a beam in
>> terms of the RB codes?
>>
>>
>> Thank you.
>>
>>
>>
>> Best regards,
>>
>> Kang
>>
>>
>> ------------------------------------------------------------
>>
>> Shinseong Kang
>> Graduate Student
>> Pusan National University, South Korea
>>
>> Tel.: +82-051-510-3052
>> H.P.: +82-010-9770-6595
>> E-mail: ss...@pu...
>>
>> ------------------------------------------------------------
>>
>

[Libmesh-users] [RE]Re: [RB] Assembly for a Interior (neighbor) side between elements

[Shinseong K. <ss...@pu...>]

Thank you for your reply, David.As youadvised, I edited that part in "RB_construction.C" and ranmy code again.As a result, I could obtain the correct result.I was able to solve the problem much simpler than I expected thanks to your help.Best regards,Kang------------------------------------------------------------
ShinseongKang
GraduateStudent
PusanNationalUniversity, South KoreaTel.: +82-051-510-3052
H.P.:+82-010-9770-6595
E-mail:ss...@pu...

----------------------------------------------------------------- Original Message -----From : David Knezevic <dav...@ak...>To : "Shinseong Kang" <ss...@pu...>Cc : "Libmesh user group" <lib...@li...>Sent : 2019-10-08 21:53:36Subject : Re: [RB] Assembly for a Interior (neighbor) side between elementsHello,I think your approach is basically correct, butissue is that by default the code skips assembly on internal sides for the sake of efficiency (since usually we do not need to do assembly on internal sides). In order to not skip internal sides you can set "impose_internal_fluxes = true" on your RBConstruction object. That is false by default and if you look atRBConstruction::add_scaled_matrix_and_vector() you will see that you have to set it to true in order to loop over non-boundary sides.Let me know if that works for you.Best,DavidOn Tue, Oct 8, 2019 at 6:57 AM Shinseong Kang <ss...@pu...> wrote:Hello, all.I triedto definean output in a simply supported 3-D beam problem.My output is an average displacement in the middle of the beam.For simplicity, I only used two brick elements, i.e, ■|■, where"■" is an element, and"|" is a location I want to compute the average output.To do this, I utilized the codes in RB example 5.First, Ideclared "ThetaOutput" (parameter-dependent term) and alsodeclared "AssemblyOutput" (parameter-independent term) as follows:=======================================voidAssemblyOutput::boundary_assembly(FEMContext & c)}=======================================As you can see, The above code is very similar to"Assemblyp1" in "assembly.C" ofRB example 5.However, I could not obtain the correct output because the above code cannot deal with interior side between elements.In other words, theboundary information of FEMContext only include outer side.I tried to find another way, but I could not find the right solution.Therefore,I'd like your help.To summarize my questions areas follows:1. Is there any way to assemble an interior (neighbor) sidebetween elements?2. How to compute anaverage displacement for the middleof a beam in terms of the RB codes?Thank you.Best regards,Kang------------------------------------------------------------
ShinseongKang
GraduateStudent
PusanNationalUniversity, South KoreaTel.: +82-051-510-3052
H.P.:+82-010-9770-6595
E-mail:ss...@pu...

------------------------------------------------------------

Re: [Libmesh-users] Clough-Tocher finite elements FECLOUGH

[Ata o. M. <a.m...@gm...>]

Thank you as always Roy.

Ata

On Tue, Oct 8, 2019 at 5:35 PM Stogner, Roy H <roy...@ic...>
wrote:

>
> On Tue, 8 Oct 2019, gmail wrote:
>
> > I was wondering what is the local numbering of the DOFs for
> > Clough-Tocher FE on Tri6 elements? I’m looking for a way in each
> > element to loop over the basis value (not the gradient) DOFs.
>
> We always locally loop over vertices, then sides, then interiors, and
> on a C1 vertex we always start with the value DoF before the gradient
> or any mixed derivative DoFs.  So local basis numbers 0, 3, and 6
> should be your value degrees of freedom.
> ---
> Roy

-- 
Best,
Ata

Re: [Libmesh-users] Clough-Tocher finite elements FECLOUGH

[Stogner, R. H <roy...@ic...>]

On Tue, 8 Oct 2019, gmail wrote:

> I was wondering what is the local numbering of the DOFs for
> Clough-Tocher FE on Tri6 elements? I’m looking for a way in each
> element to loop over the basis value (not the gradient) DOFs.

We always locally loop over vertices, then sides, then interiors, and
on a C1 vertex we always start with the value DoF before the gradient
or any mixed derivative DoFs.  So local basis numbers 0, 3, and 6
should be your value degrees of freedom.
---
Roy

[Libmesh-users] Clough-Tocher finite elements FECLOUGH

[gmail <a.m...@gm...>]

Hi,

I was wondering what is the local numbering of the DOFs for Clough-Tocher FE on Tri6 elements? I’m looking for a way in each element to loop over the basis value (not the gradient) DOFs.


Thanks,
Ata

Re: [Libmesh-users] [RB] Assembly for a Interior (neighbor) side between elements

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

Hello,

I think your approach is basically correct, but issue is that by default
the code skips assembly on internal sides for the sake of efficiency (since
usually we do not need to do assembly on internal sides). In order to not
skip internal sides you can set "impose_internal_fluxes = true" on your
RBConstruction object. That is false by default and if you look
at RBConstruction::add_scaled_matrix_and_vector() you will see that you
have to set it to true in order to loop over non-boundary sides.

Let me know if that works for you.

Best,
David

On Tue, Oct 8, 2019 at 6:57 AM Shinseong Kang <ss...@pu...> wrote:

> Hello, all.
>
>
>
> I tried to define an output in a simply supported 3-D beam problem.
>
> My output is an average displacement in the middle of the beam.
>
> For simplicity, I only used two brick elements, i.e, ■|■, where "■" is an
> element, and "|" is a location I want to compute the average output.
>
>
> To do this, I utilized the codes in RB example 5.
>
> First, I declared "ThetaOutput" (parameter-dependent term) and
> also declared "AssemblyOutput" (parameter-independent term) as follows:
>
> =======================================
>
> void  AssemblyOutput::boundary_assembly(FEMContext & c)
>
> {
>
>   if (rb_sys.get_mesh().get_boundary_info().has_boundary_id
>
>       (&c.get_elem(), c.side, BOUNDARY_ID_MID))
>
>     {
>
>       const unsigned int u_var = 0;
>
>       const unsigned int v_var = 1;
>
>
>       FEBase * side_fe = libmesh_nullptr;
>
>       c.get_side_fe(v_var, side_fe);
>
>
>       const std::vector<Real> & JxW_side = side_fe->get_JxW();
>
>
>       const std::vector<std::vector<Real> > & phi_side =
> side_fe->get_phi();
>
>
>       const unsigned int n_v_dofs = c.get_dof_indices(v_var).size();
>
>
>       unsigned int n_qpoints = c.get_side_qrule().n_points();
>
>       DenseSubVector<Number> & output = c.get_elem_residual(v_var);
>
>
>       for (unsigned int qp=0; qp < n_qpoints; qp++)
>
>         for (unsigned int i=0; i < n_v_dofs; i++)
>
>           output(i) += JxW_side[qp] * (1. * phi_side[i][qp]);
>
>     }
>
> }
>
> =======================================
> As you can see, The above code is very similar to "Assemblyp1" in
> "assembly.C" of RB example 5.
>
> However, I could not obtain the correct output because the above code
> cannot deal with interior side between elements.
> In other words, the boundary information of FEMContext only include outer
> side.
>
> I tried to find another way, but I could not find the right solution.
> Therefore, I'd like your help.
>
> To summarize my questions are as follows:
> 1. Is there any way to assemble an interior (neighbor) side between
> elements?
> 2. How to compute an average displacement for the middle of a beam in
> terms of the RB codes?
>
>
> Thank you.
>
>
>
> Best regards,
>
> Kang
>
>
> ------------------------------------------------------------
>
> Shinseong Kang
> Graduate Student
> Pusan National University, South Korea
>
> Tel.: +82-051-510-3052
> H.P.: +82-010-9770-6595
> E-mail: ss...@pu...
>
> ------------------------------------------------------------
>