FEMContext/FEMSystem users/developers,
With the minimum functionality going for vector-valued elements, I wanted
to start moving on adding support to FEMContext and FEMSystem. The main
issue is the path I want to follow will break backward compatibility, so I
wanted to discuss here first.
As was briefly mentioned in an earlier devel-thread (here:
http://sourceforge.net/mailarchive/message.php?msg_id=29247370), there are
two ways I can see moving forward on this:
1. Add data structures to stash the different finite element types
2. Move to storing FEAbstract* and down cast to the right type when needed
I'm really not a fan of the former (even though it would preserve backward
compatibility, I think) because, among other reasons, it will not scale
well as new types get added (e.g. tensor elements).
Moving to FEAbstract* will automatically break backward compatibility since
a down cast will be needed. Talking to Roy briefly, he opined that accessor
methods were long overdue for this and this would be a good time to add
them.
For interior_value, etc., the plan is to add (replace? If we're breaking
compatibility anyway, why have duplicate code sitting around?) templated
versions, e.g.
template<typename FieldType>
void FEMContext::interior_value( unsigned int var, unsigned int qp,
FieldType& value )
Thoughts/preferences?
If we're going to be going down the road of breaking backward compatibility
and adding accessor methods, what about protecting elem_solution,
elem_residual, etc.?
I'd like to start on this right away, so my plan is to add the necessary
protected element_fe data structures and populate it with FEAbstract* and
still populate the public data structures (for the time being) to shake
things out while we hash out plans here.
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
Libmesh-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-devel
