On Thu, 21 Jun 2012, Roy Stogner wrote:
> Maybe I shouldn't be encouraged here. One of these days I'll also fix
> our const_element_iterator/const_node_iterator, which currently behave
> like "Elem * const *" and "Node * const *" but which ought to be the
> equivalent of "const Elem * const *"
On Thu, 21 Jun 2012, Derek Gaston wrote:
Of course I had checked for this case before I sent my email...
however, I wasn't diligent enough I missed a "const" hanging out
after one of our inline functions in our Mesh proxy class (you don't
want to know) that was of course making it a const f
Of course I had checked for this case before I sent my email... however, I
wasn't diligent enough I missed a "const" hanging out after one of our
inline functions in our Mesh proxy class (you don't want to know) that was
of course making it a const function which was causing us to pick up the
c
On Thu, 21 Jun 2012, Derek Gaston wrote:
What's up with making this const? We have some code that depends on
elem's being non-const...
Certainly!
like changing their subdomain ids after reading the mesh.
Then you use a non-const MeshBase, and it gives you a non-const Elem.
So what give
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
Roy,
What's up with making this const? We have some code that depends on elem's
being non-const... like changing their subdomain ids after reading the mesh.
So what gives? I see your message that says that this is "correct"... but
I'm not convinced...
Derek
On Thu, Jun 21, 2012 at 5:38 PM, Paul T. Bauman 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
Thanks for the feedback.
On Thu, Jun 21, 2012 at 3:04 PM, Roy Stogner 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 ah
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 returnin
On Thu, Jun 21, 2012 at 2:39 AM, Robert 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
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_v
11 matches
Mail list logo
