[Kratos] one more iterations on the element and condition classes

kazem kamran kazemkamran en gmail.com
Mar Mar 18 12:03:03 CET 2014


I am agree with Jordi that we should decide on one function to do the
initializing and then the rest of the functions do adding/subtracting.  On
either we should do it inside the element or in the scheme, we can discuss.


In particular on the function that do this initialization, because for
example, for some elements, like the enriched ones that are condensed at
the element level, the Element::EquationIdVector() does not know the real
size as no new dof is added.


Regards

Kazem


On Tue, Mar 18, 2014 at 11:11 AM, Jordi Cotela <jcotela en cimne.upc.edu>wrote:

>  Just to keep the discussion going, I'd like to ask a few questions about
> the proposed changes. First of all, I agree with the general idea and I
> think that it will be an improvement over what we have now, but we should
> use the occasion to clearly define and document the mission and assumptions
> of each function.
>
> About the right hand side of the damping matrix (and I think that the same
> argument can be made about an eventual mass RHS), it would be very
> convenient for the fluid solvers if we don't force it to be RHS = LHS*vel.
> This is for efficiency reasons: as K=0 in fluid problems, putting the full
> RHS in the velocity terms allows us to evaluate shape functions and
> integration point quantities one less time.
>
> About initializing the matrices or adding to them, I prefer the option of
> adding, for efficiency reasons, but then we need to be very clear about who
> initializes the matrices. I'd propose that the matrices are initialized by
> the scheme (which is the class that defines how the different matrices are
> combined, after all). The sizes can be obtained from calls to
> Element::EquationIdVector() or Element::GetValuesVector() functions of the
> element (the first is already required, see
> Scheme::CalculateSystemContributions for example).
>
> Jordi
>
>
> On 03/17/2014 11:07 AM, Riccardo Rossi wrote:
>
>
> Dear All,
>
> i would like to go on with last week's discussion on the refactoring of
> Element and Condition base classes, on the line of what proposed by Josep
> Maria,
>
> Current interface is designed to implement a time integrator for a problem
> in the form
>
> M*acc + D*vel + K*disp = f
>
> where "acc" and "vel" are considered to be vectors containing the 2nd and
> 1st time derivatives of the variables in "disp".
>
>
> M was called "MassMAtrix" and "D" was called "DampingMatrix".
>
> Of course this names only make sense in structural dynamics and are not
> suitable for CFD.
> CFD systems can be often seen as the particular case in which K=0.
>
> The advantage of having a common approach for CFD and CSD is that one can
> create a monolithic method in which both a structure and a fluid are
> advanced in time using the same time integrator, in a seamless fashion.
> This objective has to be taken into account in writing the time
> integrator.
>
> In the original design, Mass and Damping matrix were assumed to be linear,
> so that their contribution to the RHS could alwasy be written as
> RHS -= D*vel
> RHS -= M*vel
>
> the original design falls short when one wants to consider non-linear
> terms in either the mass or the damping. The point is that if one wants to
> be able to correctly linearize the damping and "mass" terms one needs to be
> able to evaluate separately the contribution to the LHS and the one to the
> RHS.
> Furthermore this evaluation is best done together for efficiency reasons.
> This justifies the creation of methods of the type: (take the names are
> very temporary, for the sake of discussion)
>
> CalculateDampingRHS( Vector& RHS, ProcessInfo$ rCurrentProcessInfo);
> CalculateDampingLHS( Matrix& LHS, ProcessInfo$ rCurrentProcessInfo);
> CalculateDamping( Matrix& LHS, Vector$ RHS, ProcessInfo$
> rCurrentProcessInfo);
>
> And their analogous for the Mass (possibly renamed to Inertia)
>
> the third method could be implemented in the base class element as
> CalculateDamping(...)
> {
>      CalculateDampingLHS(...)
>      v = this->FirstDerivatives..( ...)
>      RHS = LHS*v;
> }
> so that the method is automatically available in all of the elements (and
> conditions) within kratos
>
> an IMPORTANT DECISION is wether the LHS and RHS shall be initialized
> within the element or if they  should be added/subtracted to the input
> values.
> the ADDING/SUBTRACTING option is more efficient, since it requires no
> initialization/resize of the target terms and avoid the use of temporaries,
> while the option of initializing it within the element is in principle
> more robust. One important difficulty is how the scheme should know of the
> expected size of the LHS/RHS.
>
> Having said this, and heard the critics, most probably the cleanest way to
> deal with this is to do initialization within the element, and then summing
> up the contribution in the scheme,
> that is...assuming that RHS is set to zero within the element and not
> overwritten.
>
> The problem is that this breaks the current behaviour for the function
> "CalculateLocalVelocityContribution", which shall be removed and
> substituted by the new "CalculatingDamingContribution" fucntion with two
> arguments
> I really would like to hear comments/thoughts about this... if this is
> accepted than we should go ahead.
> Also, are there suggestion on a better name instead of "Damping"?
>
>
>
> As a side comment, all the resize(0,0) shall be replaced to
> resize(0,0,false) within the base classes. Apparently this was MY original
> fault not Josep Maria's (my apologies about this), but still it is important
> to do the change.
>
> finally and as a further suggestion, the method "Initialize()" shall
> accept the current ProcessInfo as a parameter.
>
> This may also be the case for the methods
>
>     virtual void GetValuesVector(Vector& values, int Step = 0)
>     virtual void GetFirstDerivativesVector(Vector& values, int Step = 0)
>     virtual void GetSecondDerivativesVector(Vector& values, int Step = 0)
>
> again, this would be a breaking change, so please give opinions about this
> (in particular about this being relevant or no...)
>
>
>
>
>
> as a very final comment, i believe we should explcitly state a set of
> rules for procedures to change the foundational classes... i'll write a
> proposal about this
>
> ciao
> Riccardo
>
>
>
> --
>
>
> *Riccardo Rossi *
>
> PhD, Civil Engineer
>
>
>  member of the Kratos Team: www.cimne.com/kratos
>
> lecturer at Universitat Politècnica de Catalunya, BarcelonaTech (UPC)
>
> Research fellow at International Center for Numerical Methods in
> Engineering (CIMNE)
>
>
>  C/ Gran Capità, s/n, Campus Nord UPC, Ed. C1, Despatx C9
>
> 08034 - Barcelona - Spain - www.cimne.com  -
>
> T.(+34) 93 401 56 96 skype: *rougered4*
>
>
>
> <http://www.cimne.com/>
>
>  <https://www.facebook.com/cimne> <http://blog.cimne.com/><http://vimeo.com/cimne><http://www.youtube.com/user/CIMNEvideos><http://www.linkedin.com/company/cimne><https://twitter.com/cimne>
>
> Les dades personals contingudes en aquest missatge són tractades amb la
> finalitat de mantenir el contacte professional entre CIMNE i voste. Podra
> exercir els drets d'accés, rectificació, cancel·lació i oposició,
> dirigint-se a cimne en cimne.upc.edu. La utilització de la seva adreça de
> correu electronic per part de CIMNE queda subjecte a les disposicions de la
> Llei 34/2002, de Serveis de la Societat de la Informació i el Comerç
> Electronic.
>
>  Imprimiu aquest missatge, només si és estrictament necessari.
>   <http://www.cimne.com/>
>
>
> _______________________________________________
> Kratos mailing listKratos en listas.cimne.upc.eduhttp://listas.cimne.upc.edu/cgi-bin/mailman/listinfo/kratos
>
>
>
> _______________________________________________
> Kratos mailing list
> Kratos en listas.cimne.upc.edu
> http://listas.cimne.upc.edu/cgi-bin/mailman/listinfo/kratos
>
>
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: http://listas.cimne.upc.edu/pipermail/kratos/attachments/20140318/ca9abb0e/attachment.htm 


Más información sobre la lista de distribución Kratos