[Kratos] FLAGS

Riccardo Rossi rrossi en cimne.upc.edu
Vie Jun 21 09:06:38 CEST 2013


i Partially disagree on that.

using "local flags" implies explicitly assigning a different name to the
same bit of the container, which is a recipe of disaster if the flag is
used "globally" by more than one application.
for this reason one can set and use a local flag but shall assume that its
meaning IS NOT mantained during the computations. This means that local
flags can be used within a function
but their values can not be expected to last after that function finishes.
Not so for the "global flags".

for this reason, the use of "local" flags shall be only allowed very very
locally... for example as input and output of functions or internally
within each one's implementation.

a corollary of this limitation is that local flags can not be read from the
input, and hence are not useful in many of the contexts were global flags
are.

Having said this i believe that the flag list we proposed is more or less
correct, even though we should vote and remove the ones whose meaning is
largely undetermined and can lead to confusion

ciao
Riccardo







On Thu, Jun 20, 2013 at 6:04 PM, <pooyan en cimne.upc.edu> wrote:

> **
>
> Good observation of Jordi,
>
>
>
> Bests,
>
>
>
> Pooyan.
>
>
>
> On Thu, 20 Jun 2013 17:39:24 +0200, jcotela en cimne.upc.edu wrote:
>
> Dear List,
>
> after talking with Riccardo, we have realized that, once we commit a set
> of global flags, we must make sure that they are used consistently across
> applications. If the same flag is used in different applications to
> represent different things, using both applications at the same time might
> become impossible. Therefore, we should make sure that the global list only
> contains either flags that are mainly used from the Kratos core (as opposed
> to from applications) or flags that have a very clear definition (as for
> example the MPI related ones) we all can agree upon. The rest should be
> application-specific to prevent creating incompatibilities.
>
> Jordi
>
> On Thu, 20 Jun 2013 16:57:43 +0200, Riccardo Rossi wrote:
>
>  I try to collect here Josep Maria's proposal and to merge it with
> mine... i personally don't agree too much with the flags ENGAGED ,  RELEASE
> as they look to me oriented to a specific contact application
> regarding the ACTIVATED flag i think either this or DEACTIVE shall be in
> the list. Maybe not both of them as Jordi and Pooyan observe but at least
> one of the two.
>
> once more proposals arrive i'll keep merging it to the list ... please
> tell me if i happen to forget one
>
> at the end  we shall vote on which shall be kept and which not...
>
> FLUID
> STRUCTURE
> SOLID
> RIGID
> CONTACT
> BOUNDARY
> FREE_SURFACE
> INTERFACE
> ENGAGED
> ISOLATED
> REFINE
> INSERTED
> RELEASE
>
> ACTIVATED
> SLIP
> MASTER
> SLAVE
> ERASE
> MPI_BOUNDARY
> VISITED
> THERMAL
> PERMANENT
> PROTECTED
> SPLIT
> MODIFIED
> BLOCKED
>
> so far 26 flags ...
>
> ciao for now
>
> Riccardo
>
>
>
>
> On Thu, Jun 20, 2013 at 2:54 PM, Josep Maria <cpuigbo en cimne.upc.edu>wrote:
>
>>  Dear All,
>>
>>   Following the discussion about flags. I'm not for putting a f before the name of the flag, you must know what are you doing and which type of variable are you working with, if is a vector, int, double or a flag. Right now I'm using next as global flags for my application, and I propose them to be global ones. Take in account that you can have your local flags in your application objects. We impose that their names must not coincide with the global ones.
>>
>>    FLUID
>>    STRUCTURE
>>    SOLID
>>    RIGID
>>    CONTACT
>>
>>    BOUNDARY
>>    FREE_SURFACE
>>
>>    INTERFACE
>>
>>    ENGAGED
>>    ISOLATED
>>
>>    REFINE
>>    INSERTED
>>
>>    RELEASE
>>
>> Concerning to the Riccardo's proposals. I don't like this wildcard flags as MODIFIED or ACTIVE that do not specify nothing and can induce errors. I think is better to define this type of flags as local and specify what is modified or activated in its particular process. It will be good if you think about flags for the objects description (Nodes,Elements,Conditions,Meshes), and flags for processes specification (Remeshing, Building, Computing). The ones for object description must be very general. The global flags for processes description must be focussed only for the core processes and for the most general common processes shared in the important applications.
>>
>>
>> Kind Regards
>>
>> Josep Maria
>>
>> --
>>      *  Dr. Josep Maria Carbonell i Puigbó *
>>   Lecturer in Continuum Mechanics
>>    Universitat Politècnica de Catalunya (UPC)
>>    Researcher
>>    Numerical Methods in Engineering (CIMNE)
>>
>>   T  +34 934 054 068
>>   F  +34 934 016 517
>>   E  cpuigbo en cimne.upc.edu
>>
>> <%20cpuigbo en cimne.upc.edu>            CIMNE-UPC • Efidici C1, Campus
>> Nord UPC • Gran Capitàn s/n • 08034 Barcelona
>>
>> _______________________________________________
>> Kratos mailing list
>> Kratos en listas.cimne.upc.edu
>> http://listas.cimne.upc.edu/cgi-bin/mailman/listinfo/kratos
>>
>>
>
>
>
> --
>
> Dr. Riccardo Rossi, Civil Engineer
>
> Member of Kratos Team
>
> International Center for Numerical Methods in Engineering - CIMNE
> Campus Norte, Edificio C1
>
> c/ Gran Capitán s/n
>
> 08034 Barcelona, España
>
> Tel:        (+34) 93 401 56 96
>
> Fax:       (+34) 93.401.6517
> web:       www.cimne.com
>
>
>
>
>
> _______________________________________________
> Kratos mailing list
> Kratos en listas.cimne.upc.edu
> http://listas.cimne.upc.edu/cgi-bin/mailman/listinfo/kratos
>
>


-- 

Dr. Riccardo Rossi, Civil Engineer

Member of Kratos Team

International Center for Numerical Methods in Engineering - CIMNE
Campus Norte, Edificio C1

c/ Gran Capitán s/n

08034 Barcelona, España

Tel:        (+34) 93 401 56 96

Fax:       (+34) 93.401.6517
web:       www.cimne.com
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: http://listas.cimne.upc.edu/pipermail/kratos/attachments/20130621/c17ad1b7/attachment.htm 


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