From: Paul T. B. <ptb...@gm...> - 2012-06-20 22:18:06
|
I've got a compiling version of a vector Lagrange finite element; the vector part is entirely untested at this point. Patch can be found at: http://users.ices.utexas.edu/~pbauman/fe_lagrange/lagrange_vec.patch and new fe_lagrange_vec.C (to be dropped in src/fe) can be found at: http://users.ices.utexas.edu/~pbauman/fe_lagrange/fe_lagrange_vec.C This builds for me in dbg and opt and all the examples run successfully (caveat I didn't run in complex mode). The patch is against r5709 of trunk. A few things I wanted to point out and open up for criticism before I committed. 1. I had to add some void FEInterface::shape methods to handle the Real vs. RealGradient shape functions. I kept the old Real FEInterface::shape method there for backward compatibility (at Roy's suggestion). 2. FEInterface::n_vec_dim returns the number components (defaulting to 1 for a scalar type). The way this is done is by looking at the mesh dimension. Thus, we are implicitly assuming the vector dimension is tied to the mesh dimension. This, of course, will break for mixed-dimension meshes, which are currently not supported anyway. 3. Constraints aren't done yet - once we have compute_proj_contraints going for the vector case, we'll enable it. Thus, adaptivity won't work, for the moment. 4. The main thing I wanted to make sure didn't ruffle feathers: vis formats don't seem to understand vector-valued quantities, so we have to write them out component wise. I've updated build_solution_names and build_solution_vector to detect vector finite element types and write out component wise, naming each component as the original name plus "_x", "_y", and "_z" for each relevant component. In particular, all components are being packed in nodal_soln and indexing is used to pull out the right values. I haven't tested yet on the vector element, but it as least seems to be working for the scalar elements (I check gmv and ExodusII outputs in the examples). Thoughts? Best, Paul |
From: Robert <li...@ro...> - 2012-06-21 08:20:20
|
On Wed, Jun 20, 2012 at 05:17:59PM -0500, Paul T. Bauman wrote: > 4. The main thing I wanted to make sure didn't ruffle feathers: vis formats > don't seem to understand vector-valued quantities, so we have to write them out > component wise. I've updated build_solution_names and build_solution_vector to > detect vector finite element types and write out component wise, naming each > component as the original name plus "_x", "_y", and "_z" for each relevant > component. In particular, all components are being packed in nodal_soln and > indexing is used to pull out the right values. I haven't tested yet on the > vector element, but it as least seems to be working for the scalar elements (I > check gmv and ExodusII outputs in the examples). At least VTK supports also vector-valued solutions of arbitrary size. I tried 3-dimensional vectors for displacements and 6-dimensional vectors for postprocessed stresses. I currently stores these quantities in variables with suffixes "_x", "_y", "_z" and "_xx", "_xy", "_xz", "_yy", "_yx", "_zz" and have a little programm for postprocessing the resulting VTK files [1]. Robert [1] http://tmp.xenim.de/vtkfilter.tar.gz > > Thoughts? > > Best, > > Paul > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Libmesh-devel mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libmesh-devel |
From: Paul T. B. <ptb...@gm...> - 2012-06-21 14:27:41
|
On Thu, Jun 21, 2012 at 2:39 AM, Robert <li...@ro...> wrote: > > At least VTK supports also vector-valued solutions of arbitrary size. > It looks like the current VTKIO bypasses the build_solution_vector paradigm and does its own thing. Which means the splitting of variables won't apply to VTKIO. On the other hand, it probably means something will have to be done explicitly for the VTK case to handle the vector-valued variables. I've got an vector_fe example that I'm using to work out the (numerous...) kinks ATM. Once that's going, perhaps you could use that to help add that support? I know nothing about VTK internals and, since we use ExodusIO and GMV around here, I'm afraid I don't have the time to implement that capability. Thanks, Paul |
From: Roy S. <roy...@ic...> - 2012-06-21 20:04:35
|
Looking over this, only two gripes: The new FEInterface::shape should be a templated method to make it trivial to extend to RealTensor etc. This should be easy to fix after the fact; commit as-is. The FEInterface::is_vector_type() return type of bool is too restrictive - we ought to be returning a type enum (TYPE_REAL or TYPE_REAL_GRADIENT for now) to make it easier to extend later. I'll fix any problems in complex mode; the svn head is in flux right now anyway. My own ParallelMesh support edits are probably breaking --disable-amr as we speak. --- Roy On Wed, 20 Jun 2012, Paul T. Bauman wrote: > I've got a compiling version of a vector Lagrange finite element; the vector part is entirely untested at this point. Patch can be found at: > http://users.ices.utexas.edu/~pbauman/fe_lagrange/lagrange_vec.patch and new fe_lagrange_vec.C (to be dropped in src/fe) can be found at: > http://users.ices.utexas.edu/~pbauman/fe_lagrange/fe_lagrange_vec.C This builds for me in dbg and opt and all the examples run successfully > (caveat I didn't run in complex mode). |
From: Paul T. B. <ptb...@gm...> - 2012-06-21 22:38:59
|
Thanks for the feedback. On Thu, Jun 21, 2012 at 3:04 PM, Roy Stogner <roy...@ic...>wrote: > > Looking over this, only two gripes: > > The new FEInterface::shape should be a templated method to make it > trivial to extend to RealTensor etc. This should be easy to fix after > the fact; commit as-is. > Went ahead and fixed this. > > The FEInterface::is_vector_type() return type of bool is too > restrictive - we ought to be returning a type enum (TYPE_REAL or > TYPE_REAL_GRADIENT for now) to make it easier to extend later. > Will do. How does everyone feel about "FieldType" as the enum type for this? > > I'll fix any problems in complex mode; the svn head is in flux right > now anyway. My own ParallelMesh support edits are probably breaking > --disable-amr as we speak. > OK, thanks. I hadn't committed before now, but since that time, I have found many kinks and now have a working example! The example is extending introduction_ex3 and is solving two uncoupled Laplace equations. I have it dumping GMV and ExodusII - I checked both (ParaView for ExodusII) output and everything seems to be working. Among the changes beyond what I had before are the following: 1. An FEBase::build needed to go to FEAbstract::build in dof_map during initialization 2. The shape function code for fe_lagrange_vec.C before was wrong, fixed now. 3. Fixed some bugs in my initial update of build_solution_names and build_solution_vector for output. Works for all old examples and the new vector_fe_ex1 4. As mentioned above, I templated the new void FEInterface::shape functions. I tested with gcc 4.5 in dbg and opt modes and intel 11.1 in opt mode. Caveats: 1. I haven't tested restart capability, but it should "just work" for XDR. ExodusII_IO::read will not work for these variables at the moment. 2. Although compute_constraints is enabled for FELagrangeVec, I haven't tested it on adapted meshes. In particular, we still need to test compute_proj_constraints for vector-valued elements. 3. I've only tested GMV and ExodusII_IO, not sure if this has broken others or not. 4. Have not tested on complex-valued problems. I'm sure there's plenty of other stuff I haven't thought of yet, but please let me know if this breaks you. Committed in r5717. I'll work on the enum type right away, but please chime in if you don't like the FieldType name. Of course, if I hosed you, please let me know ASAP. Next on the agenda is to update FEMSystem/FEMContext to handle this. More to come... Best, Paul |
From: Paul T. B. <ptb...@gm...> - 2012-06-22 01:26:33
|
On Thu, Jun 21, 2012 at 5:38 PM, Paul T. Bauman <ptb...@gm...> wrote: > The FEInterface::is_vector_type() return type of bool is too >> restrictive - we ought to be returning a type enum (TYPE_REAL or >> TYPE_REAL_GRADIENT for now) to make it easier to extend later. >> > > Will do. How does everyone feel about "FieldType" as the enum type for > this? > I went with FEFieldType and renamed FEInterface::is_vector_type to FEInterface::field_type, which returns an FEFieldType. Committed in r5719. Let me know if you don't like it and I'll change it. Thanks, Paul |