From: David K. <dknez@MIT.EDU> - 2009-04-20 01:03:31
Attachments:
extra_dof_stuff.tar.gz
|
OK, so I've got a simple version of this working. I've attached a patch, as well as some new files for the instantiation of FEScalar (I sent this earlier, but didn't zip it up, so it didn't make it under the 40kb limit) Some notes: - As a first cut, I used lots of hacks in dof_map.h that will only work in serial - I used Roy's idea of letting the Order of SCALAR indicate how many scalar variables we want -- I guess then it would be good to make sure that we only add one SCALAR to a system, but I haven't done that yet... - I didn't (yet) make any changes to the sparsity pattern, so adding to the last row(s) and column(s) of the matrix will be slow - Plotting the SCALAR variables gives garbage at the moment, although I guess it should be easy to change GMVIO etc to plot the constant value of the SCALAR I've attached a test example (lagrange_mult.C) for this functionality, using a Lagrange multiplier to solve a pure (homogeneous) Neumann problem, and enforcing that \int_\Omega u \dx = 5. - Dave Roy Stogner wrote: > > On Sat, 18 Apr 2009, David Knezevic wrote: > >> So, I'd really like to add this system.add_variable(foo,SCALAR) >> functionality to libMesh. I've been poking around the library, but I'm >> not really sure how to get started, so I could definitely use some >> pointers... >> >> It seems to me that the important details for this are in DofMap, for >> storing and retrieving the dof index of the scalar variable, as well as >> for setting the sparsity pattern/number of non-zeros...? > > That's right. > >> Some thoughts I've had are: >> >> - Add a new enum SCALAR to FEFamily (or alternatively, a new enum SCALAR >> to Order)? > > FEFamily. The Order would then specify how many scalars to add. > > Maybe next write an FE<SCALAR> specialization? Something that acted > sort of like a discontinuous monomial element? That might help > avoiding the need to add special cases to a lot of loops in the > library later. > >> - Short circuit all the loops over elements for DOF counting in DofMap >> for SCALAR variables, > > If the FE<SCALAR> claimed to have zero dofs per element, DofMap would > basically skip right over it... but I'm not sure that's an intuitive > behavior; this might be a loop you really do want a special case on. > >> and instead store the dof index of each SCALAR variable in a vector >> in DofMap? > > Right. > >> - However, I can't see where in the code one should compute the dof >> index of a SCALAR variable in the first place? > > That's all in dof_map.C. > >> - Ben, regarding setting the nonzero count and the number of rows that >> you mentioned; where is this controlled? In SparsityPattern? > > In SparseMatrix, I believe, although the code to build the sparsity > pattern is in DofMap. > --- > Roy > |
From: Roy S. <roy...@ic...> - 2009-04-24 20:28:27
|
On Sun, 19 Apr 2009, David Knezevic wrote: > OK, so I've got a simple version of what we've discussed working. > > I've attached a patch, as well as some new files for the instantiation of > FEScalar. > > Some notes: > - As a first cut, I used lots of hacks in dof_map.h that will only work in > serial Will only work in serial, and will only work when there's no more than one SCALAR variable added, right? Would it be inconvenient if we fixed those two things before adding the patch to SVN? If the answer is "yes", I'll add it now. (likewise if the answer is "shouldn't you be getting --enable-parmesh and --enable-ghosted working already?") Patch looks great otherwise. > - I used Roy's idea of letting the Order of SCALAR indicate how many scalar > variables we want -- I guess then it would be good to make sure that we only > add one SCALAR to a system, but I haven't done that yet... It could be more convenient in the long run if we enabled adding many SCALARs to a system - some multiphysics codes might be made up of parts that each want to add their own scalar variable(s) without first consulting with each other. > - I didn't (yet) make any changes to the sparsity pattern, so adding to the > last row(s) and column(s) of the matrix will be slow Horrifyingly slow, from the users' reports we've had over the years. PETSc really was designed to work best if you get the memory allocation right the first time. But your priorities are right: get things working and tested now and we'll optimize later. > - Plotting the SCALAR variables gives garbage at the moment, although I guess > it should be easy to change GMVIO etc to plot the constant value of the > SCALAR Changing GMVIO would only be the start - then we have to change VTKIO, then every other output format. For formats that allow "metadata" scalars to be attached, that's how we need to do it, but for general visualization formats, it might be convenient to just make FE<SCALAR> behave enough like FE<MONOMIAL> that it works on its own (for low-Order scalars). --- Roy |
From: David K. <dknez@MIT.EDU> - 2009-04-24 20:49:09
|
Hi Roy, >> - As a first cut, I used lots of hacks in dof_map.h that will only >> work in serial > > Will only work in serial, and will only work when there's no more than > one SCALAR variable added, right? > > Would it be inconvenient if we fixed those two things before adding > the patch to SVN? If the answer is "yes", I'll add it now. (likewise > if the answer is "shouldn't you be getting --enable-parmesh and > --enable-ghosted working already?") Patch looks great otherwise. Making it possible to add multiple SCALARs would not be difficult, I can take care of that. Getting it to work in parallel may be a bit trickier (at least for me). How about I take care of the first point and have another look at what would be required to get it going in parallel before you add the patch. > Horrifyingly slow, from the users' reports we've had over the years. > PETSc really was designed to work best if you get the memory > allocation right the first time. But your priorities are right: get > things working and tested now and we'll optimize later. Sounds good. - Dave |
From: Roy S. <roy...@ic...> - 2009-04-24 20:58:29
|
On Fri, 24 Apr 2009, David Knezevic wrote: > Making it possible to add multiple SCALARs would not be difficult, I can take > care of that. Getting it to work in parallel may be a bit trickier (at least > for me). How about I take care of the first point and have another look at > what would be required to get it going in parallel before you add the patch. Hmm... add the multiple SCALARs stuff now if it's easy, add a test that fails to libmesh_error() if DofMap sees a scalar with n_processors() > 1, and then we'll add the patch from there. I'm not averse to adding in-progress code to SVN, I just don't want it to fail silently if anyone not on the mailing list notices and tries out the capability. --- Roy |
From: David K. <dknez@MIT.EDU> - 2009-04-24 21:02:22
|
> Hmm... add the multiple SCALARs stuff now if it's easy, add a test > that fails to libmesh_error() if DofMap sees a scalar with > n_processors() > 1, and then we'll add the patch from there. I'm not > averse to adding in-progress code to SVN, I just don't want it to > fail silently if anyone not on the mailing list notices and tries out > the capability. Sounds good. Just to let you know, I probably won't get onto this until next week (lots of balls in the air right now). - Dave |
From: David K. <dknez@MIT.EDU> - 2009-04-29 03:37:48
Attachments:
SCALAR_patch.gz
|
Hi Roy, So, I've added the multiple SCALARs stuff (see the patch), and that works fine. To do this I added a std::map member to DofMap to store the Order of each SCALAR. Also, I added the SCALAR code from DofMap::dof_indices to DofMap::old_dof_indices, with n_old_dofs() in place of n_dofs(). However, I realized that a system with a SCALAR variable breaks on calling equation_systems.reinit() after doing (say) a uniform refinement, since vector projection calls fe_scalar_shape_2D.C. I haven't looked at this in detail yet, but I guess we should just map each SCALAR value in the old vector to the corresponding entry in the projected vector... - Dave Roy Stogner wrote: > > On Fri, 24 Apr 2009, David Knezevic wrote: > >> Making it possible to add multiple SCALARs would not be difficult, I >> can take care of that. Getting it to work in parallel may be a bit >> trickier (at least for me). How about I take care of the first point >> and have another look at what would be required to get it going in >> parallel before you add the patch. > > Hmm... add the multiple SCALARs stuff now if it's easy, add a test > that fails to libmesh_error() if DofMap sees a scalar with > n_processors() > 1, and then we'll add the patch from there. I'm not > averse to adding in-progress code to SVN, I just don't want it to > fail silently if anyone not on the mailing list notices and tries out > the capability. > --- > Roy > |
From: Roy S. <roy...@ic...> - 2009-04-30 16:38:51
|
On Tue, 28 Apr 2009, David Knezevic wrote: > So, I've added the multiple SCALARs stuff (see the patch), and that works > fine. To do this I added a std::map member to DofMap to store the Order of > each SCALAR. Do we need that? We've already committed the sin of duplicating data once, so we might as well take advantage of that: we should be able to grab the variable order data from DofMap::_variables. > Also, I added the SCALAR code from DofMap::dof_indices to > DofMap::old_dof_indices, with n_old_dofs() in place of n_dofs(). Thanks; that will be important. > However, I realized that a system with a SCALAR variable breaks on calling > equation_systems.reinit() after doing (say) a uniform refinement, since > vector projection calls fe_scalar_shape_2D.C. I haven't looked at this in > detail yet, but I guess we should just map each SCALAR value in the old > vector to the corresponding entry in the projected vector... Right. And if that's too much work for now, just stick a libmesh_not_implemented() inside a loop testing for SCALARs in System::project_vector(), I think. Likewise, let's switch those libmesh_error() calls in DofMap to libmesh_not_implemented() --- Roy |
From: David K. <dknez@MIT.EDU> - 2009-04-30 16:43:43
|
> Do we need that? We've already committed the sin of duplicating data > once, so we might as well take advantage of that: we should be able to > grab the variable order data from DofMap::_variables. Oh yeah, of course. I'll fix that. > Right. And if that's too much work for now, just stick a > libmesh_not_implemented() inside a loop testing for SCALARs in > System::project_vector(), I think. Likewise, let's switch those > libmesh_error() calls in DofMap to libmesh_not_implemented() OK, no problem. - Dave |
From: David K. <dknez@MIT.EDU> - 2009-04-30 17:50:41
Attachments:
SCALAR-patch.gz
|
Hi Roy, This patch should take care of those changes. - Dave Roy Stogner wrote: > > On Tue, 28 Apr 2009, David Knezevic wrote: > >> So, I've added the multiple SCALARs stuff (see the patch), and that >> works fine. To do this I added a std::map member to DofMap to store >> the Order of each SCALAR. > > Do we need that? We've already committed the sin of duplicating data > once, so we might as well take advantage of that: we should be able to > grab the variable order data from DofMap::_variables. > >> Also, I added the SCALAR code from DofMap::dof_indices to >> DofMap::old_dof_indices, with n_old_dofs() in place of n_dofs(). > > Thanks; that will be important. > >> However, I realized that a system with a SCALAR variable breaks on >> calling equation_systems.reinit() after doing (say) a uniform >> refinement, since vector projection calls fe_scalar_shape_2D.C. I >> haven't looked at this in detail yet, but I guess we should just map >> each SCALAR value in the old vector to the corresponding entry in the >> projected vector... > > Right. And if that's too much work for now, just stick a > libmesh_not_implemented() inside a loop testing for SCALARs in > System::project_vector(), I think. Likewise, let's switch those > libmesh_error() calls in DofMap to libmesh_not_implemented() > --- > Roy |
From: Roy S. <roy...@ic...> - 2009-04-30 18:44:21
|
On Thu, 30 Apr 2009, David Knezevic wrote: > This patch should take care of those changes. Looks good. You've got svn write access, right? This looks about ready to commit. Would you add a _n_SCALAR_dofs(0) initializer to the DofMap constructor first, though? Thanks, --- Roy |
From: David K. <dknez@MIT.EDU> - 2009-04-30 18:51:35
|
> Looks good. You've got svn write access, right? This looks about > ready to commit. OK, great. Yep I do have svn access, back from the days when John and I added ex0. > Would you add a _n_SCALAR_dofs(0) initializer to the DofMap > constructor first, though? Thanks, Yep. - Dave |
From: David K. <dknez@MIT.EDU> - 2009-04-19 23:55:44
|
OK, so I've got a simple version of what we've discussed working. I've attached a patch, as well as some new files for the instantiation of FEScalar. Some notes: - As a first cut, I used lots of hacks in dof_map.h that will only work in serial - I used Roy's idea of letting the Order of SCALAR indicate how many scalar variables we want -- I guess then it would be good to make sure that we only add one SCALAR to a system, but I haven't done that yet... - I didn't (yet) make any changes to the sparsity pattern, so adding to the last row(s) and column(s) of the matrix will be slow - Plotting the SCALAR variables gives garbage at the moment, although I guess it should be easy to change GMVIO etc to plot the constant value of the SCALAR I've attached an test example for this functionality, using a Lagrange multiplier to solve a pure (homogeneous) Neumann problem, and enforcing that \int_\Omega u \dx = 5. - Dave Roy Stogner wrote: > > On Sat, 18 Apr 2009, David Knezevic wrote: > >> So, I'd really like to add this system.add_variable(foo,SCALAR) >> functionality to libMesh. I've been poking around the library, but I'm >> not really sure how to get started, so I could definitely use some >> pointers... >> >> It seems to me that the important details for this are in DofMap, for >> storing and retrieving the dof index of the scalar variable, as well as >> for setting the sparsity pattern/number of non-zeros...? > > That's right. > >> Some thoughts I've had are: >> >> - Add a new enum SCALAR to FEFamily (or alternatively, a new enum SCALAR >> to Order)? > > FEFamily. The Order would then specify how many scalars to add. > > Maybe next write an FE<SCALAR> specialization? Something that acted > sort of like a discontinuous monomial element? That might help > avoiding the need to add special cases to a lot of loops in the > library later. > >> - Short circuit all the loops over elements for DOF counting in DofMap >> for SCALAR variables, > > If the FE<SCALAR> claimed to have zero dofs per element, DofMap would > basically skip right over it... but I'm not sure that's an intuitive > behavior; this might be a loop you really do want a special case on. > >> and instead store the dof index of each SCALAR variable in a vector >> in DofMap? > > Right. > >> - However, I can't see where in the code one should compute the dof >> index of a SCALAR variable in the first place? > > That's all in dof_map.C. > >> - Ben, regarding setting the nonzero count and the number of rows that >> you mentioned; where is this controlled? In SparsityPattern? > > In SparseMatrix, I believe, although the code to build the sparsity > pattern is in DofMap. > --- > Roy |
From: David K. <dknez@MIT.EDU> - 2009-05-08 19:16:28
|
heh I guess that made its way through the mail filter :) I've learnt my lesson: attachments need to be less than 40kb David Knezevic wrote: > OK, so I've got a simple version of what we've discussed working. > > I've attached a patch, as well as some new files for the instantiation > of FEScalar. > > Some notes: > - As a first cut, I used lots of hacks in dof_map.h that will only work > in serial > - I used Roy's idea of letting the Order of SCALAR indicate how many > scalar variables we want -- I guess then it would be good to make sure > that we only add one SCALAR to a system, but I haven't done that yet... > - I didn't (yet) make any changes to the sparsity pattern, so adding to > the last row(s) and column(s) of the matrix will be slow > - Plotting the SCALAR variables gives garbage at the moment, although I > guess it should be easy to change GMVIO etc to plot the constant value > of the SCALAR > > I've attached an test example for this functionality, using a Lagrange > multiplier to solve a pure (homogeneous) Neumann problem, and enforcing > that \int_\Omega u \dx = 5. > > - Dave > > > > Roy Stogner wrote: >> >> On Sat, 18 Apr 2009, David Knezevic wrote: >> >>> So, I'd really like to add this system.add_variable(foo,SCALAR) >>> functionality to libMesh. I've been poking around the library, but I'm >>> not really sure how to get started, so I could definitely use some >>> pointers... >>> >>> It seems to me that the important details for this are in DofMap, for >>> storing and retrieving the dof index of the scalar variable, as well as >>> for setting the sparsity pattern/number of non-zeros...? >> >> That's right. >> >>> Some thoughts I've had are: >>> >>> - Add a new enum SCALAR to FEFamily (or alternatively, a new enum SCALAR >>> to Order)? >> >> FEFamily. The Order would then specify how many scalars to add. >> >> Maybe next write an FE<SCALAR> specialization? Something that acted >> sort of like a discontinuous monomial element? That might help >> avoiding the need to add special cases to a lot of loops in the >> library later. >> >>> - Short circuit all the loops over elements for DOF counting in DofMap >>> for SCALAR variables, >> >> If the FE<SCALAR> claimed to have zero dofs per element, DofMap would >> basically skip right over it... but I'm not sure that's an intuitive >> behavior; this might be a loop you really do want a special case on. >> >>> and instead store the dof index of each SCALAR variable in a vector >>> in DofMap? >> >> Right. >> >>> - However, I can't see where in the code one should compute the dof >>> index of a SCALAR variable in the first place? >> >> That's all in dof_map.C. >> >>> - Ben, regarding setting the nonzero count and the number of rows that >>> you mentioned; where is this controlled? In SparsityPattern? >> >> In SparseMatrix, I believe, although the code to build the sparsity >> pattern is in DofMap. >> --- >> Roy > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------------ > The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your > production scanning environment may not be a perfect world - but thanks to > Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 > Series Scanner you'll get full speed at 300 dpi even with all image > processing features enabled. http://p.sf.net/sfu/kodak-com > > > ------------------------------------------------------------------------ > > _______________________________________________ > Libmesh-devel mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libmesh-devel |
From: David K. <dknez@MIT.EDU> - 2009-04-20 00:04:26
|
OK, so I've got a simple version of what we've discussed working. I've attached a patch, as well as some new files for the instantiation of FEScalar. Some notes: - As a first cut, I used lots of hacks in dof_map.h that will only work in serial - I used Roy's idea of letting the Order of SCALAR indicate how many scalar variables we want -- I guess then it would be good to make sure that we only add one SCALAR to a system, but I haven't done that yet... - I didn't (yet) make any changes to the sparsity pattern, so adding to the last row(s) and column(s) of the matrix will be slow - Plotting the SCALAR variables gives garbage at the moment, although I guess it should be easy to change GMVIO etc to plot the constant value of the SCALAR I'll attach an example program to another email since if I attach it here it puts me over the 40kb limit. - Dave Roy Stogner wrote: > > On Sat, 18 Apr 2009, David Knezevic wrote: > >> So, I'd really like to add this system.add_variable(foo,SCALAR) >> functionality to libMesh. I've been poking around the library, but I'm >> not really sure how to get started, so I could definitely use some >> pointers... >> >> It seems to me that the important details for this are in DofMap, for >> storing and retrieving the dof index of the scalar variable, as well as >> for setting the sparsity pattern/number of non-zeros...? > > That's right. > >> Some thoughts I've had are: >> >> - Add a new enum SCALAR to FEFamily (or alternatively, a new enum SCALAR >> to Order)? > > FEFamily. The Order would then specify how many scalars to add. > > Maybe next write an FE<SCALAR> specialization? Something that acted > sort of like a discontinuous monomial element? That might help > avoiding the need to add special cases to a lot of loops in the > library later. > >> - Short circuit all the loops over elements for DOF counting in DofMap >> for SCALAR variables, > > If the FE<SCALAR> claimed to have zero dofs per element, DofMap would > basically skip right over it... but I'm not sure that's an intuitive > behavior; this might be a loop you really do want a special case on. > >> and instead store the dof index of each SCALAR variable in a vector >> in DofMap? > > Right. > >> - However, I can't see where in the code one should compute the dof >> index of a SCALAR variable in the first place? > > That's all in dof_map.C. > >> - Ben, regarding setting the nonzero count and the number of rows that >> you mentioned; where is this controlled? In SparsityPattern? > > In SparseMatrix, I believe, although the code to build the sparsity > pattern is in DofMap. > --- > Roy > |