From: Paul T. B. <ptb...@gm...> - 2012-06-22 03:06:19
|
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 |