[Kratos] proposal of change in the solving_strategy

maireni en cimne.upc.edu maireni en cimne.upc.edu
Mie Oct 7 12:36:35 CEST 2015


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


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