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

Jordi Cotela jcotela en cimne.upc.edu
Mar Mar 18 11:11:18 CET 2014

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).


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 
> <http://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 <http://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 
> <mailto: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 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/ef553bfb/attachment.htm 

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