[Kratos] proposal of change in the solving_strategy

Carlos Roig roigcarlo en gmail.com
Jue Oct 8 10:42:58 CEST 2015


Hi Bui,

There are already several implementations of search trees already present
in Kratos. You can find them here:

https://kratos.cimne.upc.es/projects/kratos/repository/show/kratos/kratos/spatial_containers

You will also find several other search data strucutres like bins as well.

Br,

Charlie



El mié., 7 oct. 2015 a las 12:37, <maireni en cimne.upc.edu> escribió:

>
> Dear Riccardo,
> If you put a high loading that make the structure enter to
> pastic region meaby you can or not reaches some convenrgences (sometimes
> simply do not converge because plastic is incremental).
> This thing is for the same load, during the  newton rapshon iteration
> process, the model can pass from pastic behavior (mainly those element
> where the load are applied ) to elastic behavior for redistribution of
> residual and internal forces.
> I am not good explain this in english but look the following:
>
> Begin NR method
> Initialize solution step()
> while not converge do
> {
>    Update internal variables to previous converged one (the last step
> converged)
>    {
>     Variable_new = Variable_old; /// you jus have it
>    }
>      Integrate internal forces
>      Calculate constitutive matrix
>      Fint-Fext<convergence
> }
>
> Finalize Solution Step(Update internal odl variables)
> {
> Variable_old = Variable_new
> }
>
> If this is this situation, just an updates variables during the NR
> iteration need to be called ALWAYS.
> Take care about the load because in plastic regime you can or nor have
> convervence.
> This is the way that in Structural application is design.
> I dont know if i follow your idea, but is really necesary to have this
> function in the strategy separately.
>
> In any case, if you see that is good idea, you can add a new function in
> strategy but keeping the original
> member strategy base (Es mi humilde opinion).
>
> Regards
>
> Nelson
>
>
> El 2015-10-07 18:09, Hoang Giang Bui escribió:
> > Dear all
> >
> > This addition is not harmful in my point of view. I just want to
> > comment a bit on that. Basically in the case of structural solver, the
> > new SolveSolutionStep function will comprise of:
> >
> > Clear the linear system
> >
> > loop until convergence:
> >   scheme.InitializeNonLinIteration
> >   builder_and_solver.Build
> >   linear_solver.Solve
> >
> >   scheme.FinalizeNonLinIteration
> >
> > We wrap it under the name ExecuteIteration anyway (see
> > uzawa_contact_strategy.py). Therefore it's just a name change.
> >
> > Cheers,
> >
> > Bui
> >
> > P/S: Is there a bounding volume tree implementation for efficient
> > contact search already in the Kratos kernel/ else where in the
> > application? I just want to know if I can use a better implementation,
> > otherwise I will contribute my one to the repository.
> >
> > On Wed, Oct 7, 2015 at 11:57 AM, Riccardo Rossi <rrossi en cimne.upc.edu>
> > wrote:
> >
> >> Dear Nelson,
> >>
> >>  the point is the following:
> >>
> >> imagine that you do a FSI simulation and your structure is
> >> elastoplastic: you first have a  wrong guess (too high)  of the
> >> forces acting on the structure and you call "solve". The structure
> >> becomes plastic and after reaching convergence it calls
> >> FinalizeSolutionStep where the constitutive law stores the internal
> >> variables for the next step.
> >>
> >> then you correct the forces (now much smaller) and you call solve
> >> again. The structure should not become plastic anymore HOWEVER it
> >> already stored the internal variables at the end of the previous
> >> step, so the results would wrongly believe that the structural
> >> behaviour is plastic, while really should have stayed elastic
> >>
> >> still... note that if you call "Solve" it will behave only as
> >> before. The difference is that you can choose when your Internal
> >> variables have to be stored (at the end of the complete fsi loop,
> >> not at the end of each solve!!)
> >>
> >> cheers
> >>
> >> Riccardo
> >>
> >> On Wed, Oct 7, 2015 at 9:40 AM, <maireni en cimne.upc.edu> wrote:
> >>
> >>> Hi Riccardo,
> >>>
> >>> I do not understrand yet why it is not necessary to call the
> >>> initialize,
> >>> predict and finalize functions.
> >>> This methods are escencially important in structural and solid
> >>> application where some internal variables
> >>> or other need to be updated or reseted (mainly  in constitutive
> >>> law).
> >>> If bassically  does not want to call this method i prefere in my
> >>> opinion
> >>> to include a new member in base
> >>> class of strategy where those calls can be avoided.
> >>>
> >>> It really cost calls this function in each time step?
> >>>
> >>> Regards
> >>>
> >>> Nelson
> >>>
> >>> El 2015-10-07 15:05, Riccardo Rossi escribió:
> >>>> Dear All,
> >>>>
> >>>>   i believe there is a weakness in the current design of the
> >>> solving
> >>>> strategies, and i would like to propose a small improvement to
> >>> the
> >>>> current interface:
> >>>>
> >>>> the point is that as of today the strategy has essentially the
> >>>> following methods:
> >>>>
> >>>> Initialize (to be called once)
> >>>> InitializeSolutionStep
> >>>> Predict
> >>>> FinalizeSolutionStep
> >>>>
> >>>> and
> >>>>
> >>>> Solve --> which combines everything in one single call.
> >>>>
> >>>> the problem is that is someone calls solve the
> >>> InitializeSolutionStep
> >>>> and FinalizeSolutionStep are inevitably called, which is a
> >>> problem if
> >>>> for example one
> >>>> would like to do repeated solves within a single time step.
> >>>>
> >>>> the typical scenario is that of a FSI simulation, but the same
> >>> problem
> >>>> is also found for example in the RVE solver.
> >>>>
> >>>> My proposal would be to add a new function
> >>>>
> >>>> "SolveSolutionStep"
> >>>>
> >>>> which ONLY does the solution but WITHOUT CALLING
> >>>> InitializeSolutionStep, Predict, FinalizeSolutionStep
> >>>>
> >>>> The point of doing this is that the "solve" call would be:
> >>>>
> >>>> Solve()
> >>>>     InitializeSolutionStep
> >>>>     Predict
> >>>>     SolveSolutionStep
> >>>>     FinalizeSolutionStep
> >>>>
> >>>> but one would be able to call the very same thing from the
> >>> python (or
> >>>> from a higher level strategy)
> >>>>
> >>>> so that for example a FSI loop would become
> >>>>
> >>>>     structural_solver.InitializeSolutionStep()
> >>>>     fluid_solver.InitializeSolutionStep()
> >>>>
> >>>>     structural_solver.Predict()
> >>>>
> >>>>     while(not converged)
> >>>>         structural_solver.SolveSolutionStep()
> >>>>
> >>>>         apply_velocities_to_fluid()
> >>>>
> >>>>         fluid_solver.SolveSolutionStep()
> >>>>
> >>>>         apply_forces_to_structure()
> >>>>
> >>>>         check_convergence()
> >>>>
> >>>>     structural_solver.FinalizeSolutionStep()
> >>>>     fluid_solver.FinalizeSolutionStep()
> >>>>
> >>>>
> >>>> Of course if someone uses the current Solve() nothing changes
> >>> and
> >>>> current behaviour is unmodified...
> >>>>
> >>>> any voice against such change? if not i'll go ahead...
> >>>>
> >>>> ciao
> >>>> Riccardo
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>>
> >>>> Riccardo Rossi
> >>>>
> >>>>   PhD, Civil Engineer
> >>>>
> >>>> member of the Kratos Team: www.cimne.com/kratos [1] [1]
> >>>>
> >>>> 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 [2] [2]  -
> >>>>
> >>>>   T.(+34) 93 401 56 96 [3] skype: ROUGERED4
> >>>>
> >>>>
> >>>>
> >>>>   [3]
> >>>>
> >>>>   [4] [5] [6] [7] [8] [9]
> >>>>
> >>>> 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. [3]
> >>>>
> >>>> Links:
> >>>> ------
> >>>> [1] http://www.cimne.com/kratos [1]
> >>>> [2] http://www.cimne.com [2]
> >>>> [3] http://www.cimne.com/ [4]
> >>>> [4] https://www.facebook.com/cimne [5]
> >>>> [5] http://blog.cimne.com/ [6]
> >>>> [6] http://vimeo.com/cimne [7]
> >>>> [7] http://www.youtube.com/user/CIMNEvideos [8]
> >>>> [8] http://www.linkedin.com/company/cimne [9]
> >>>> [9] https://twitter.com/cimne [10]
> >>>>
> >>>> _______________________________________________
> >>>> Kratos mailing list
> >>>> Kratos en listas.cimne.upc.edu
> >>>> http://listas.cimne.upc.edu/cgi-bin/mailman/listinfo/kratos
> >>> [11]
> >>> _______________________________________________
> >>> Kratos mailing list
> >>> Kratos en listas.cimne.upc.edu
> >>> http://listas.cimne.upc.edu/cgi-bin/mailman/listinfo/kratos [11]
> >>
> >> --
> >>
> >> Riccardo Rossi
> >>
> >> PhD, Civil Engineer
> >>
> >> member of the Kratos Team: www.cimne.com/kratos [1]
> >>
> >> 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 [2]  -
> >>
> >> T.(+34) 93 401 56 96 skype: ROUGERED4
> >>
> >>
> >>
> >> [4]
> >>
> >> [5] [6] [7] [8] [9] [10]
> >>
> >> 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.
> >> [4]
> >> _______________________________________________
> >> Kratos mailing list
> >> Kratos en listas.cimne.upc.edu
> >> http://listas.cimne.upc.edu/cgi-bin/mailman/listinfo/kratos [11]
> >
> > --
> >
> > With Best Regards !
> > Giang Bui
> > To learn and to excel
> >
> > Links:
> > ------
> > [1] http://www.cimne.com/kratos
> > [2] http://www.cimne.com
> > [3] tel:%28%2B34%29%2093%20401%2056%2096
> > [4] http://www.cimne.com/
> > [5] https://www.facebook.com/cimne
> > [6] http://blog.cimne.com/
> > [7] http://vimeo.com/cimne
> > [8] http://www.youtube.com/user/CIMNEvideos
> > [9] http://www.linkedin.com/company/cimne
> > [10] https://twitter.com/cimne
> > [11] http://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
> _______________________________________________
> 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/20151008/eaca151d/attachment-0001.htm 


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