Screenshot instructions:
Windows
Mac
Red Hat Linux
Ubuntu
Click URL instructions:
Rightclick on ad, choose "Copy Link", then paste here →
(This may not be possible with some types of ads)
You can subscribe to this list here.
2003 
_{Jan}

_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}
(2) 
_{Oct}
(2) 
_{Nov}
(27) 
_{Dec}
(31) 

2004 
_{Jan}
(6) 
_{Feb}
(15) 
_{Mar}
(33) 
_{Apr}
(10) 
_{May}
(46) 
_{Jun}
(11) 
_{Jul}
(21) 
_{Aug}
(15) 
_{Sep}
(13) 
_{Oct}
(23) 
_{Nov}
(1) 
_{Dec}
(8) 
2005 
_{Jan}
(27) 
_{Feb}
(57) 
_{Mar}
(86) 
_{Apr}
(23) 
_{May}
(37) 
_{Jun}
(34) 
_{Jul}
(24) 
_{Aug}
(17) 
_{Sep}
(50) 
_{Oct}
(24) 
_{Nov}
(10) 
_{Dec}
(60) 
2006 
_{Jan}
(47) 
_{Feb}
(46) 
_{Mar}
(127) 
_{Apr}
(19) 
_{May}
(26) 
_{Jun}
(62) 
_{Jul}
(47) 
_{Aug}
(51) 
_{Sep}
(61) 
_{Oct}
(42) 
_{Nov}
(50) 
_{Dec}
(33) 
2007 
_{Jan}
(60) 
_{Feb}
(55) 
_{Mar}
(77) 
_{Apr}
(102) 
_{May}
(82) 
_{Jun}
(102) 
_{Jul}
(169) 
_{Aug}
(117) 
_{Sep}
(80) 
_{Oct}
(37) 
_{Nov}
(51) 
_{Dec}
(43) 
2008 
_{Jan}
(71) 
_{Feb}
(94) 
_{Mar}
(98) 
_{Apr}
(125) 
_{May}
(54) 
_{Jun}
(119) 
_{Jul}
(60) 
_{Aug}
(111) 
_{Sep}
(118) 
_{Oct}
(125) 
_{Nov}
(119) 
_{Dec}
(94) 
2009 
_{Jan}
(109) 
_{Feb}
(38) 
_{Mar}
(93) 
_{Apr}
(88) 
_{May}
(29) 
_{Jun}
(57) 
_{Jul}
(53) 
_{Aug}
(48) 
_{Sep}
(68) 
_{Oct}
(151) 
_{Nov}
(23) 
_{Dec}
(35) 
2010 
_{Jan}
(84) 
_{Feb}
(60) 
_{Mar}
(184) 
_{Apr}
(112) 
_{May}
(60) 
_{Jun}
(90) 
_{Jul}
(23) 
_{Aug}
(70) 
_{Sep}
(119) 
_{Oct}
(27) 
_{Nov}
(47) 
_{Dec}
(54) 
2011 
_{Jan}
(22) 
_{Feb}
(19) 
_{Mar}
(92) 
_{Apr}
(93) 
_{May}
(35) 
_{Jun}
(91) 
_{Jul}
(32) 
_{Aug}
(61) 
_{Sep}
(7) 
_{Oct}
(69) 
_{Nov}
(81) 
_{Dec}
(23) 
2012 
_{Jan}
(64) 
_{Feb}
(95) 
_{Mar}
(35) 
_{Apr}
(36) 
_{May}
(63) 
_{Jun}
(98) 
_{Jul}
(70) 
_{Aug}
(171) 
_{Sep}
(149) 
_{Oct}
(64) 
_{Nov}
(67) 
_{Dec}
(126) 
2013 
_{Jan}
(108) 
_{Feb}
(104) 
_{Mar}
(171) 
_{Apr}
(133) 
_{May}
(108) 
_{Jun}
(100) 
_{Jul}
(93) 
_{Aug}
(126) 
_{Sep}
(74) 
_{Oct}
(59) 
_{Nov}
(145) 
_{Dec}
(93) 
2014 
_{Jan}
(38) 
_{Feb}
(45) 
_{Mar}
(26) 
_{Apr}
(41) 
_{May}
(125) 
_{Jun}
(70) 
_{Jul}
(61) 
_{Aug}
(66) 
_{Sep}
(60) 
_{Oct}
(110) 
_{Nov}
(27) 
_{Dec}
(30) 
2015 
_{Jan}
(43) 
_{Feb}
(67) 
_{Mar}
(71) 
_{Apr}
(92) 
_{May}
(39) 
_{Jun}
(15) 
_{Jul}
(46) 
_{Aug}
(63) 
_{Sep}
(84) 
_{Oct}
(82) 
_{Nov}
(69) 
_{Dec}
(45) 
2016 
_{Jan}
(92) 
_{Feb}
(91) 
_{Mar}
(148) 
_{Apr}
(43) 
_{May}
(58) 
_{Jun}
(117) 
_{Jul}
(92) 
_{Aug}
(140) 
_{Sep}
(49) 
_{Oct}
(33) 
_{Nov}
(85) 
_{Dec}
(40) 
2017 
_{Jan}
(41) 
_{Feb}
(36) 
_{Mar}
(49) 
_{Apr}
(41) 
_{May}
(73) 
_{Jun}
(51) 
_{Jul}
(12) 
_{Aug}
(69) 
_{Sep}
(26) 
_{Oct}
(43) 
_{Nov}
(75) 
_{Dec}
(23) 
2018 
_{Jan}
(86) 
_{Feb}
(36) 
_{Mar}
(24) 
_{Apr}

_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

From: David Knezevic <david.knezevic@ak...>  20180317 14:07:06

On Sat, Mar 17, 2018 at 3:50 AM, 吴家桦Gauvain <causegauvain@...> wrote: > Hi all, > > In order to know the details about the PODGreedy algorithm implemented > in TransientRBSystem for reduced basis construction, I referred to the > paper > > *B. Haasdonk, M. Ohlberger, Reduced basis method for finite volume > approximations of parametrized evolution equations, M2AN (Math. Model. > Numer. Anal.) 42 (2) (2008) 277–302.* > > invoked by > > *A highperformance parallel implementation of the certified reduced basis > method **David J. Knezevic , John W. Peterson b* > > when the TransientRBSystem is discussed. However, the algorithms proposed > by the former are PCA with fixspace and the selection of time index > associate with the largest error bound change. Neither of them mentions the > POD, which makes me confused. Could anyone give me more information on > the PODGreedy > algorithm used in libmesh? Thanks in advance. > That paper by Haasdonk and Ohlberger is the main reference for PODGreedy. I guess PCA is equivalent to POD in this context. You can refer to this paper <https://dspace.mit.edu/openaccessdisseminate/1721.1/61956>; (Section 4.2) for another description of the approach. David 
From: 吴家桦Gauvain <causegauvain@gm...>  20180317 07:50:59

Hi all, In order to know the details about the PODGreedy algorithm implemented in TransientRBSystem for reduced basis construction, I referred to the paper *B. Haasdonk, M. Ohlberger, Reduced basis method for finite volume approximations of parametrized evolution equations, M2AN (Math. Model. Numer. Anal.) 42 (2) (2008) 277–302.* invoked by *A highperformance parallel implementation of the certified reduced basis method **David J. Knezevic , John W. Peterson b* when the TransientRBSystem is discussed. However, the algorithms proposed by the former are PCA with fixspace and the selection of time index associate with the largest error bound change. Neither of them mentions the POD, which makes me confused. Could anyone give me more information on the PODGreedy algorithm used in libmesh? Thanks in advance. Regards, Gauvain  
From: Roy Stogner <roystgnr@ic...>  20180313 20:56:12

On Tue, 13 Mar 2018, Vasileios Vavourakis wrote: > oh, I thought that the default setting in the Parallel::Communicator (i.e. see default > constructor: http://libmesh.github.io/doxygen/classlibMesh_1_1Parallel_1_1Communicator.html#a697f8e599333609a45761828e14659c1) for the > “communicator” is: MPI_COMM_SELF It is, but init.comm() isn't a defaultconstructor communicator, it's a defaultformostusers communicator. Typically when someone runs on N processors it's because they want everything parallelized between N processors, so we make it easy to get an AllNProcessors communicator. > unless it gets initialised to MPI_COMM_WORLD somewhere in the > LibMeshInit  apologies, i’m not always successful looking for some > details in the library documentation :( That's a very polite way to say "Why don't you even have a single line of documentation for LibMeshInit::comm()?" I would have been tempted to phrase that with much more cursing. I'll put together a PR with better comments now, so it'll get into the online Doxygen eventually. > I will give it a spin and update libmeshusers asap... Thanks,  Roy 
From: Vasileios Vavourakis <vasvav@gm...>  20180313 19:36:46

thanks Roy for the quick turnaround. my comments below to your reply… > On 13 Mar 2018, at 21:02, Roy Stogner <roystgnr@...> wrote: > > > On Tue, 13 Mar 2018, Vasileios Vavourakis wrote: > >> I would like to run (in parallel mode) a piece of libMesh code where on >> each processor, a libMesh::Mesh is initialised & stored locally and, hence, >> subsequently initialise the EquationSystems accordingly, and for each >> processor independently. >> >> The FE mesh, may be same for all processors, or different, but in principle >> the information need to be stored independently (and partitioned in one >> subdomain/partition) without any problems when running things in parallel. >> >> I have tried to enforce the partitioning of the mesh via, e.g.: >> >> LibMeshInit init(argc, argv); >> Mesh msh(init.comm(), 1); >> //...import the mesh... >> msh.prepare_for_use(); >> msh.partition(1); >> // >> EquationSystems es(msh); >> // ...add a system here... >> es.init(); >> // ...solve the system, etc... >> >> However, I noticed that should I run the code in that many processes as >> many as the number of elements of the mesh, then it is ok; else it freezes >> (especially at a point where I "update_global_solution". >> Does this make sense to you? > > Yes, I'm afraid so. Although you might have told the mesh to give > every element to processor 0, when you created the mesh with > init.comm(), you made every processor on that communicator (i.e. every > processor in this case, since init defaults to MPI_COMM_WORLD) an > owner of that mesh. When you do collective operations on a mesh, even > processors who don't own any elements on the mesh must be involved if > they're part of that mesh's communicator. oh, I thought that the default setting in the Parallel::Communicator (i.e. see default constructor: http://libmesh.github.io/doxygen/classlibMesh_1_1Parallel_1_1Communicator.html#a697f8e599333609a45761828e14659c1 <http://libmesh.github.io/doxygen/classlibMesh_1_1Parallel_1_1Communicator.html#a697f8e599333609a45761828e14659c1>;) for the “communicator” is: MPI_COMM_SELF unless it gets initialised to MPI_COMM_WORLD somewhere in the LibMeshInit  apologies, i’m not always successful looking for some details in the library documentation :( > >> Any suggestions / tips? >> >> I am afraid there might be an easy way to do it, however, I wanted to have >> your opinion about it. > > I *think* the thing to do would be to create a new Parallel::Communicator > wrapper around MPI_COMM_SELF, then use that to create a local Mesh. done; will create a separate Communicator object, e.g.: LibMeshInit init(argc, argv); Communicator lcomm(MPI_COMM_SELF); Mesh msh(lcomm, 1); //...import the mesh... msh.prepare_for_use(); // EquationSystems es(msh); // ...add a system here... es.init(); // ...solve the system, etc... I will give it a spin and update libmeshusers asap... cheers, Vasileios > > I've never done that before, though. If you do it and it works, we'd > love to have a unit test to make sure it *stays* working through > future library updates. If you do it and it doesn't work, let us know > and (especially if you can set up a failing test case) I'll try to > help figure out what's wrong. >  > Roy 
From: Roy Stogner <roystgnr@ic...>  20180313 19:02:30

On Tue, 13 Mar 2018, Vasileios Vavourakis wrote: > I would like to run (in parallel mode) a piece of libMesh code where on > each processor, a libMesh::Mesh is initialised & stored locally and, hence, > subsequently initialise the EquationSystems accordingly, and for each > processor independently. > > The FE mesh, may be same for all processors, or different, but in principle > the information need to be stored independently (and partitioned in one > subdomain/partition) without any problems when running things in parallel. > > I have tried to enforce the partitioning of the mesh via, e.g.: > > LibMeshInit init(argc, argv); > Mesh msh(init.comm(), 1); > //...import the mesh... > msh.prepare_for_use(); > msh.partition(1); > // > EquationSystems es(msh); > // ...add a system here... > es.init(); > // ...solve the system, etc... > > However, I noticed that should I run the code in that many processes as > many as the number of elements of the mesh, then it is ok; else it freezes > (especially at a point where I "update_global_solution". > Does this make sense to you? Yes, I'm afraid so. Although you might have told the mesh to give every element to processor 0, when you created the mesh with init.comm(), you made every processor on that communicator (i.e. every processor in this case, since init defaults to MPI_COMM_WORLD) an owner of that mesh. When you do collective operations on a mesh, even processors who don't own any elements on the mesh must be involved if they're part of that mesh's communicator. > Any suggestions / tips? > > I am afraid there might be an easy way to do it, however, I wanted to have > your opinion about it. I *think* the thing to do would be to create a new Parallel::Communicator wrapper around MPI_COMM_SELF, then use that to create a local Mesh. I've never done that before, though. If you do it and it works, we'd love to have a unit test to make sure it *stays* working through future library updates. If you do it and it doesn't work, let us know and (especially if you can set up a failing test case) I'll try to help figure out what's wrong.  Roy 
From: Vasileios Vavourakis <vasvav@gm...>  20180313 14:18:50

Dear libMesh users/developers, I would like to run (in parallel mode) a piece of libMesh code where on each processor, a libMesh::Mesh is initialised & stored locally and, hence, subsequently initialise the EquationSystems accordingly, and for each processor independently. The FE mesh, may be same for all processors, or different, but in principle the information need to be stored independently (and partitioned in one subdomain/partition) without any problems when running things in parallel. I have tried to enforce the partitioning of the mesh via, e.g.: LibMeshInit init(argc, argv); Mesh msh(init.comm(), 1); //...import the mesh... msh.prepare_for_use(); msh.partition(1); // EquationSystems es(msh); // ...add a system here... es.init(); // ...solve the system, etc... However, I noticed that should I run the code in that many processes as many as the number of elements of the mesh, then it is ok; else it freezes (especially at a point where I "update_global_solution". Does this make sense to you? Any suggestions / tips? I am afraid there might be an easy way to do it, however, I wanted to have your opinion about it. cheers, Vasileios 
From: David Knezevic <david.knezevic@ak...>  20180309 20:02:56

On Fri, Mar 9, 2018 at 2:53 PM, Roy Stogner <roystgnr@...> wrote: > > On Fri, 9 Mar 2018, David Knezevic wrote: > >  If I were to look into adding a special case for nonuniform 1st >> to 2nd order refinement for LAGRANGE variables, do you think this >> would be of interest to include that in libMesh, or would it be too >> specific to include? (I'd like to know if it's potentially of >> broader interest before looking further into this.) >> > > Uninteresting to me, but I try like mad to avoid writing > LAGRANGEspecific code, so if I want C0 p refinement I just use > HIERARCHIC. Others who've coded themselves too far into a > LAGRANGEonly corner might disagree... but from what I've seen the > very first way to screw up is to assume that every node has a dof for > every variable, and any code like that will *still* be broken if those > users have secondorder geometric elements (so they can support p=2) > but start with p=1. > >  How complex do you think it would be to add that special case? >> > > Not very. I personally don't think it's worth it when you'd just end > up stuck restricted by p<=2 anyways, but if anyone else disagrees I'd > still happily merge their work. ;) > OK, thanks for that info. I'll think some more about whether this is worth working on or not for my usecase. Thanks, David 
From: Roy Stogner <roystgnr@ic...>  20180309 19:53:58

On Fri, 9 Mar 2018, David Knezevic wrote: >  If I were to look into adding a special case for nonuniform 1st > to 2nd order refinement for LAGRANGE variables, do you think this > would be of interest to include that in libMesh, or would it be too > specific to include? (I'd like to know if it's potentially of > broader interest before looking further into this.) Uninteresting to me, but I try like mad to avoid writing LAGRANGEspecific code, so if I want C0 p refinement I just use HIERARCHIC. Others who've coded themselves too far into a LAGRANGEonly corner might disagree... but from what I've seen the very first way to screw up is to assume that every node has a dof for every variable, and any code like that will *still* be broken if those users have secondorder geometric elements (so they can support p=2) but start with p=1. >  How complex do you think it would be to add that special case? Not very. I personally don't think it's worth it when you'd just end up stuck restricted by p<=2 anyways, but if anyone else disagrees I'd still happily merge their work. ;)  Roy 
From: David Knezevic <david.knezevic@ak...>  20180309 19:32:32

On Fri, Mar 9, 2018 at 2:21 PM, Roy Stogner <roystgnr@...> wrote: > prefinement is supported, but adaptive prefinement currently isn't. > We require basis functions to be hierarchic (not necessarily > HIERARCHIC) to generate constraint equations between neighboring > elements of different p refinement levels. > > So you can do uniform refinement for error estimation, but that's > about it. > OK, got it, thanks. Two questions:  If I were to look into adding a special case for nonuniform 1st to 2nd order refinement for LAGRANGE variables, do you think this would be of interest to include that in libMesh, or would it be too specific to include? (I'd like to know if it's potentially of broader interest before looking further into this.)  How complex do you think it would be to add that special case? David 
From: Roy Stogner <roystgnr@ic...>  20180309 19:21:28

prefinement is supported, but adaptive prefinement currently isn't. We require basis functions to be hierarchic (not necessarily HIERARCHIC) to generate constraint equations between neighboring elements of different p refinement levels. So you can do uniform refinement for error estimation, but that's about it.  Roy 
From: David Knezevic <david.knezevic@ak...>  20180309 19:06:51

I'm using LAGRANGE variables for an elasticity problem and I'd like to be able to increase the variable order from 1 to 2 specified elements. Is it possible to do this using prefinement in libMesh? I had a vague impression that prefinement was only supported for discontinuous or hierachic basis functions, but from looking at the fe_lagrange*.C code it seems that it does use elem>p_level(), so I wanted to check if libMesh already handles this case? If so, does it automatically constrain with hanging nodes on the interface of first and second order elements (I guess this is almost the same as AMR so maybe it's already supported)? Thanks, David 
From: John Peterson <jwpeterson@gm...>  20180308 22:11:47

Hello all, There have been quite a few changes since the 1.2.x series in Summer 2017, the biggest of which is probably that libMesh now requires a C++11conforming compiler. For a more detailed list of changes in this release, see: https://github.com/libMesh/libmesh/blob/v1.3.0rc1/NEWS For links to the packaged tarballs, visit: https://github.com/libMesh/libmesh/releases/tag/v1.3.0rc1 As always, we appreciate any feedback you can provide on your experiences with downloading and building this release. Thanks, John 
From: Roy Stogner <roystgnr@ic...>  20180308 16:00:12

On Thu, 8 Mar 2018, MohamedAziz.NASRI@... wrote: > I have recently installed Libmesh and i try to use it. In fact, I > have my C++ code working on a single Gauss point. Is it possible to > use Libmesh with my code in order to obtain my finite element code > (like Moose framework). Unfortunately there isn't a user manual for > that. Is there someone who has already doing this? Lots of people; independent uses of libMesh predate (and based on published papers might still be more popular than) uses of middleware frameworks. But there's no user manual for it because there's no one right way to do it  if there was then we'd just encapsulate that way in the One True Framework and nobody would use anything else. Most independent libMesh application developers start with whichever of the examples is closest to what they're developing, and add complexity from there.  Roy 
From: <MohamedAziz.NASRI@en...>  20180308 10:29:24

Hello, I have recently installed Libmesh and i try to use it. In fact, I have my C++ code working on a single Gauss point. Is it possible to use Libmesh with my code in order to obtain my finite element code (like Moose framework). Unfortunately there isn't a user manual for that. Is there someone who has already doing this? Best regards, Aziz 
From: Manav Bhatia <bhatiamanav@gm...>  20180301 17:36:14

Hi, I am using DofMap::add_constrain_row() to constrain some dofs to zero: libMesh::DofConstraintRow c_row; dof_map.add_constraint_row(*dof_it, c_row, true); This is implemented in an object derived from System::Constrain. Then, I call System::reinit_constraints() before assembly. This has been working fine, but I have one case that is tripping the following error when I call SparseMatrix::add_matrix(). I am going to start to dig into this to figure out why this might be happening, but if there are any quick words of advice, that would be very helpful. I am a bit puzzled since this is for a diagonal entry. My understanding is that constraining dofs should not remove them from the sparsity pattern. I guess I am missing something here. Regards, Manav [1;31m[0]PETSC ERROR:  Error Message  [0;39m[0;49m[0]PETSC ERROR: Argument out of range [0]PETSC ERROR: New nonzero at (7308,7308) caused a malloc Use MatSetOption(A, MAT_NEW_NONZERO_ALLOCATION_ERR, PETSC_FALSE) to turn off this check [0]PETSC ERROR: See http://www.mcs.anl.gov/petsc/documentation/faq.html for trouble shooting. [0]PETSC ERROR: Petsc Release Version 3.8.0, unknown [0]PETSC ERROR: /Users/manav/Library/Developer/Xcode/DerivedData/mast_workspacehfyswujevmwgyugsmyueuaouvmkj/Build/Products/Debug/example_driver on a archdarwincopt named Dhcp90164.HPC.MsState.Edu by manav Thu Mar 1 10:42:54 2018 [0]PETSC ERROR: Configure options prefix=/Users/manav/Documents/codes/numerical_lib/petsc/petsc/../ CC=mpiccopenmpiclang40 CXX=mpicxxopenmpiclang40 FC=mpif90openmpiclang40 withfortran=0 withmpiexec=/opt/local/bin/mpiexecopenmpiclang40 withsharedlibraries=1 withx=1 withxdir=/opt/X11 withdebugging=0 withlapacklib=/usr/lib/liblapack.dylib withblaslib=/usr/lib/libblas.dylib downloadsuperlu=yes downloadsuperlu_dist=yes downloadsuitesparse=yes downloadmumps=yes downloadscalapack=yes downloadparmetis=yes downloadmetis=yes downloadhypre=yes downloadml=yes [0]PETSC ERROR: #1 MatSetValues_SeqAIJ() line 481 in /Users/manav/Documents/codes/numerical_lib/petsc/petsc/src/mat/impls/aij/seq/aij.c [0]PETSC ERROR: #2 MatSetValues() line 1270 in /Users/manav/Documents/codes/numerical_lib/petsc/petsc/src/mat/interface/matrix.c 
From: Roy Stogner <roystgnr@ic...>  20180301 17:05:26

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. > 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  Roy 
From: David Knezevic <david.knezevic@ak...>  20180301 17:04:50

On Thu, Mar 1, 2018 at 12:00 PM, John Peterson <jwpeterson@...> wrote: > > > On Thu, Mar 1, 2018 at 9:30 AM, David Knezevic <david.knezevic@... > > wrote: > >> On Thu, Mar 1, 2018 at 10:50 AM, Roy Stogner <roystgnr@...> >> 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 userdefined 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 > OK, thanks! David 
From: John Peterson <jwpeterson@gm...>  20180301 17:01:14

On Thu, Mar 1, 2018 at 9:30 AM, David Knezevic <david.knezevic@...> wrote: > On Thu, Mar 1, 2018 at 10:50 AM, Roy Stogner <roystgnr@...> > 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 userdefined 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 
From: David Knezevic <david.knezevic@ak...>  20180301 16:48:32

On Thu, Mar 1, 2018 at 11:46 AM, Roy Stogner <roystgnr@...> wrote: > > On Thu, 1 Mar 2018, David Knezevic wrote: > > On Thu, Mar 1, 2018 at 10:50 AM, Roy Stogner <roystgnr@...> >> 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 easilybroken (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 
From: Roy Stogner <roystgnr@ic...>  20180301 16:46:31

On Thu, 1 Mar 2018, David Knezevic wrote: > On Thu, Mar 1, 2018 at 10:50 AM, Roy Stogner <roystgnr@...> 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 easilybroken (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 
From: John Peterson <jwpeterson@gm...>  20180301 16:43:16

On Wed, Feb 28, 2018 at 8:11 PM, David Knezevic <david.knezevic@...> 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 userdefined forward and inverse periodic boundary transform functions in MOOSE if you'd like to check and see how it's done there.  John 
From: David Knezevic <david.knezevic@ak...>  20180301 16:36:36

On Thu, Mar 1, 2018 at 10:50 AM, Roy Stogner <roystgnr@...> 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 userdefined 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 
From: 吴家桦Gauvain <causegauvain@gm...>  20180301 08:00:13

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 20180228 0:44 GMT+08:00 David Knezevic <david.knezevic@...>: > On Tue, Feb 27, 2018 at 9:48 AM, 吴家桦Gauvain <causegauvain@...> > 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 > steadystate 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. > > > 20180227 22:00 GMT+08:00 David Knezevic <david.knezevic@...>: >> >>> On Tue, Feb 27, 2018 at 8:55 AM, 吴家桦Gauvain <causegauvain@...> >>> 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 >>> >>> >>> >>> >>>> 20180227 21:21 GMT+08:00 David Knezevic <david.knezevic@...>: >>>> >>>>> On Tue, Feb 27, 2018 at 4:03 AM, 吴家桦Gauvain <causegauvain@...> >>>>> 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.45303e07 >>>>>> ... >>>>>> last eigenvalue = 1.90536e07 >>>>>> >>>>>> 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)%206300622>* >> *Email:g <gauvainwu@...>auvain.wujiahua@... >> <auvain.wujiahua@...>* >> 中山大学中法核工程与技术学院学生 >> Institut FrancoChinois de l'Energie >> Nucléaire, L'université Sun Yatsen >> > >  *吴家桦 Gauvain* *Mobile:13316300622* *Email:g <gauvainwu@...>auvain.wujiahua@... <auvain.wujiahua@...>* 中山大学中法核工程与技术学院学生 Institut FrancoChinois de l'Energie Nucléaire, L'université Sun Yatsen 
From: David Knezevic <david.knezevic@ak...>  20180301 05:46:38

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 
From: Michael Povolotskyi <mpovolot@pu...>  20180228 17:22:27

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. 