Normally you don't need to "iterate over components". Normally you would
just use the overloaded operators to do vector arithmetic.
For instance, for a PDE term that looks like "div grad u" the volume
portion of the weak form looks like "grad u * grad phi_i" (where phi_i is
your test function). In code... you simply write something like this:
grad_u[qp] * grad_phi[i][qp]
That automatically does a vector-vector dot product (inner product). It is
also dimension (and element / shape function) independent.
But, yes, if you do need to iterate over components (for some reason) just
iterate to LIBMESH_DIM:
for (unsigned int i = 0; i < LIBMESH_DIM; i++)
std::cout<<grad_phi[i][qp](i)<<std::endl;
Derek
On Sun, Aug 21, 2016 at 11:51 AM Mike Marchywka <marchy...@hotmail.com>
wrote:
>
>
>
>
>
> ----------------------------------------
> > Date: Sun, 21 Aug 2016 10:17:41 -0500
> > From: royst...@ices.utexas.edu
> > To: marchy...@hotmail.com
> > CC: libmesh-users@lists.sourceforge.net
> > Subject: Re: [Libmesh-users] what is the deal with TypeVector size()?
> >
> >
> > On Sun, 21 Aug 2016, Mike Marchywka wrote:
> >
> >> It apparently is a deprecated way to get a norm which would seem at odds
> >> with both math and programming conventions.
> >
> > That is in fact why it's deprecated, yes. It's been deprecated long
> > enough that we should probably remove it entirely in the next release;
> > old users should have had time to change over by now and new users
> > would be better served by a compile-time failure instead of a run-time
> > warning.
> >
> >> Further, AFAICT, it is always 3D
> >
> > It's always LIBMESH_DIM dimensional; a constant defaulting to 3 and
> > set at configure time. Usually 2D problems are cheap enough that
> > people don't bother to worry about optimizing them, but there's
> > occasionally someone who has to run a zillion 2D problems as the inner
> > part of an optimization or uncertainty quantification loop and so we
> > try to keep --enable-2D-only from regressing.
> >
>
> Just offhand this seems like something suited for templates. While the
> efficiency issue may be minor it seems more natural to use templates
> here rather than sizes defined at lib build time. At least provide a loop
> limit
> that returns the constant where ever defined. size() const { return
> LIBMESH_DIM; }?
> But again templates are there and things like 2D cross products can assume
> a zero z and return something with a 3rd component. I suppose a 3D vector
> if constructed with a 2 D ctor could just consider itself 2D and anyone who
> does not care can loop over the zero third D.
>
> The examples seem to use lots of compile time constants and AFAICT right
> now,
> I would not mind at all recompiling to add a new species to a simulation.
> And the same
> would be fine for dimensions just not rebuilding the whole lib or having a
> second to
> link against when I may want to mix and match. Say for example having a 2D
> and 3D system that interact in some way that you may want to do them in
> isolation
> and then iterate until they are consistent with each other. Would this
> never occur?
>
> >> forcing an anyone wanting to use it would have to know otherwise how
> >> many matter or just loop over wasted zeroes.
> >
> > Right.
>
> So what is the best way to iterate over components? Use LIBMESH_DIM?
>
> Thanks.
>
> > ---
> > Roy
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Libmesh-users mailing list
> Libmesh-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/libmesh-users
>
------------------------------------------------------------------------------
_______________________________________________
Libmesh-users mailing list
Libmesh-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-users
