________________________________
> From: fried...@gmail.com
> Date: Sun, 21 Aug 2016 16:29:33 +0000
> Subject: Re: [Libmesh-users] what is the deal with TypeVector size()?
> To: marchy...@hotmail.com; royst...@ices.utexas.edu
> CC: libmesh-users@lists.sourceforge.net
>
> 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.
The examples that have tensor or outer products loop with hard coded
3. Also after I reorged some Ke summation loops values changed
slightly but understandably if due to precision issues. Maybe if I let the
thing converge better results
would be the same but I would like to know exactly what is going on in some
cases.
Do your apps typically end up being FLOP or memory access limited?
It just sounds like tossing in an extra zero is easy to prevent and could
become a bottleneck. I was also surprised that with 54 instead of
3 the results often looked plausible as almost everything was a denorm :)
I guess there was no compiler warning since the real was just used
in a for loop, i<size() lol.
Thanks.
>
> 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<mailto:marchy...@hotmail.com>> wrote:
>
>
>
>
>
> ----------------------------------------
>> Date: Sun, 21 Aug 2016 10:17:41 -0500
>> From: royst...@ices.utexas.edu<mailto:royst...@ices.utexas.edu>
>> To: marchy...@hotmail.com<mailto:marchy...@hotmail.com>
>> CC:
> libmesh-users@lists.sourceforge.net<mailto: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<mailto: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
