[Kratos] FLAGS

Riccardo Rossi rrossi en cimne.upc.edu
Vie Jun 21 11:20:23 CEST 2013


Jordi, don't know the exact answer for your second question...Pooyan has
the only voice on that

Riccardo



On Fri, Jun 21, 2013 at 11:19 AM, Riccardo Rossi <rrossi en cimne.upc.edu>wrote:

> Jordi,
>           the thing is that "global flags" shall be used more or less as
> normal variables (of course with a difference in the actual usage)
>
> while "local flags" are special things
>
> Riccardo
>
>
>
> On Fri, Jun 21, 2013 at 10:25 AM, <jcotela en cimne.upc.edu> wrote:
>
>> **
>>
>> Riccardo,
>>
>> while I see your point, I believe that precisely for this reason global
>> flags are much more dangerous. If we assume that the value of local flags
>> is not maintained during the computations (that is, that future function
>> calls cannot trust that the value that will be read is the same it has
>> now), that is a design limitation we must live with. However, if we assume
>> that the value of global flags is preserved, but we don't enforce it,
>> allowing other parts of the code to modify them, that is a recipe for
>> disaster.
>>
>> On a different subject, what is the space we are allocating to flags? I
>> seem to remember it was 32 global and 32 local (or application-specific)
>> flags, but that was a long time ago. Is there a difference in use between
>> the two? Could we split them in other ways (say 16-48) depending on the
>> "demand" for flags?
>>
>> Jordi
>>
>>
>>
>> On Fri, 21 Jun 2013 09:06:38 +0200, Riccardo Rossi wrote:
>>
>>   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
>>
>>
>>
>> _______________________________________________
>> 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
>



-- 

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/9ccd3339/attachment-0001.htm 


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