________________________________
> From: fried...@gmail.com
> Date: Mon, 22 Aug 2016 16:56:31 +0000
> Subject: Re: [Libmesh-users] DenseSubMatrix and DenseSubVector lack of
> ctor and operators
> To: marchy...@hotmail.com; jwpeter...@gmail.com
> CC: libmesh-users@lists.sourceforge.net
>
> Mike: you seem overly concerned with optimization even though you are
> just getting started. Optimization is something better handled after
> you have your application working. Try to write good solid code that
> makes sense first.
I tried that and the compiler did not like it because of the way you designed
the classes...
I was curious why you did that so the code would be more solid and optimization
is one possibility
although no one did mention the rationale behind making the size() of
a fixed size vector into a norm - it sounds like you are still deprecating
things as you go.
It would be easier to get it working if I could move code around freely
with normal operations being permitted. That biock of initialization may not
seem like a big deal but I'm trying to move stuff that does not seem critical
out of the way and at each step rebuild and test a few results such as
extreme values of the solution and overall shape in "R" plots.
Thanks.
>
> Right now you are just guessing at what's going to be slow... the only
> way to know is to build your application and then use a profiler to see
> where the time is going and try to target those areas with
> optimization.
>
> For instance: if you are doing an implicit calculation then your linear
> solver and preconditioner are likely going to take up 80% (or more) of
> your solve time... so optimizing your FE assembly won't matter much.
>
> Now: that's not a reason to be sloppy... But libMesh has endured for
> ~15 years at this point and it's anything but sloppy.
>
> Just some advice...
>
> Derek
> On Mon, Aug 22, 2016 at 10:51 AM Mike Marchywka
> <marchy...@hotmail.com<mailto:marchy...@hotmail.com>> wrote:
>
>
>
>
>
> ________________________________
>> From: jwpeter...@gmail.com<mailto:jwpeter...@gmail.com>
>> Date: Mon, 22 Aug 2016 08:28:18 -0600
>> Subject: Re: [Libmesh-users] DenseSubMatrix and DenseSubVector lack of
>> ctor and operators
>> To: marchy...@hotmail.com<mailto:marchy...@hotmail.com>
>> CC:
> libmesh-users@lists.sourceforge.net<mailto:libmesh-users@lists.sourceforge.net>
>
>>
>>
>>
>> On Mon, Aug 22, 2016 at 7:53 AM, Mike Marchywka
>>
> <marchy...@hotmail.com<mailto:marchy...@hotmail.com><mailto:marchy...@hotmail.com<mailto:marchy...@hotmail.com>>>
>
> wrote:
>> I was trying to move some code around related to the vars typically
>> called Ke and Fe
>> but encountered several errors due to missing ctor or operators such as
>> assignment.
>> Can someone comment on the benefit of or need for these restrictions?
>>
>> I think you are probably referring to a default constructor for
>> DenseSubMatrix, i.e. one that does not need a reference to a parent
>> matrix in order to be created? I don't think this is a good
>> idea/necessary, as it would introduce extra bookkeeping and potentially
>> make DenseSubMatrix too easy to use incorrectly...
>>
>>
>> I was trying to clean up
>> my own code a bit and debating about how to handle things which seem
> to often
>> be compile time constants. One possibility is to create a code
> generator that
>> creates specific c++ code for a given set of conditions. This is ok if
>> there are some
>> compiler optimizations that just not easy with other approaches. Thanks.
>>
>>
>>
>> DMN Ke; DVN Fe;
>> //DSM Ke_var; DSV Fe_var;
>> DSM Ke_var; // [mla.nvar][mla.nvar];
>> DSV Fe_var; // [mla.nvar] ;
>> // InitMats(Ke,Fe,Ke_var,Fe_var,mla.nvar);
>>
>> What specifically is a compile-time constant limitation here from libmesh?
>>
>>
>>
>> //const IdxTy dofsz=dof_indices.size();
>> //const IdxTy dofsz=mla.di.dof_indices_var[0].size();
>> //Ke.resize (dofsz,dofsz); Fe.resize (dofsz);
>> /*
>> DSM Ke_var[mla.nvar][mla.nvar] =
>> {
>> { DSM(Ke), DSM(Ke), DSM(Ke), DSM(Ke)},
>> { DSM(Ke), DSM(Ke), DSM(Ke), DSM(Ke)},
>> { DSM(Ke), DSM(Ke), DSM(Ke), DSM(Ke)},
>> { DSM(Ke), DSM(Ke), DSM(Ke), DSM(Ke)}
>> };
>>
>> DSV Fe_var[mla.nvar] = {DSV(Fe), DSV(Fe), DSV(Fe), DSV(Fe) };
>>
>> Are you just wanting to know how to create dynamically-size 2D arrays
>> at runtime?
>
> Yes, I guess that would do it but then the question is why
> the examples differ from that method. Certainly compile time
> does give the compiler more opportunities to optimize.
>
> There is any object that can do this internally,
>
> Ty * Ke_var_data = new Ty[n*m] ?
>
> and I would have guessed that for best performance you have some way of
> organizing memory.
>
>>From what I have now, I only need to be able to interface to these
> things from the
> function that assembles the FEM RHS and LHS,
>
> dof_map.constrain_element_matrix_and_vector (Ke, Fe, dof_indices);
> system.matrix->add_matrix (Ke, dof_indices);
> system.rhs->add_vector (Fe, dof_indices);
>
> I could probably check the documentation but are any of there templated
> or accept iterators
> or do they require these libmesh DenseSub types?
>
> Thanks.
>
>
>>
>> --
>> John
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> 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
