[Kratos] FLAGS

jcotela en cimne.upc.edu jcotela en cimne.upc.edu
Vie Jun 21 10:25:10 CEST 2013


  

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,
wrote:
> 
>> Good observation of Jordi, 
>> 
>> Bests, 
>> 
>> Pooyan.

>> 
>> On Thu, 20 Jun 2013 17:39:24 +0200, jcotela en cimne.upc.edu [5]
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 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 
>>>>> 
>>>>> CIMNE-UPC * Efidici C1,
Campus Nord UPC * Gran Capitàn s/n * 08034 Barcelona
>>>>> 
>>>>>
_______________________________________________
>>>>> Kratos mailing
list
>>>>> Kratos en listas.cimne.upc.edu [1]
>>>>>
http://listas.cimne.upc.edu/cgi-bin/mailman/listinfo/kratos [2]
>>>>

>>>> -- 
>>>> 
>>>> 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 [4]
>> 
>>
_______________________________________________
>> Kratos mailing
list
>> Kratos en listas.cimne.upc.edu [6]
>>
http://listas.cimne.upc.edu/cgi-bin/mailman/listinfo/kratos [7]
> 
> --

> 
> 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 [9]

 

Links:
------
[1]
mailto:Kratos en listas.cimne.upc.edu
[2]
http://listas.cimne.upc.edu/cgi-bin/mailman/listinfo/kratos
[3]
mailto:cpuigbo en cimne.upc.edu
[4] http://www.cimne.com/
[5]
mailto:jcotela en cimne.upc.edu
[6] mailto:Kratos en listas.cimne.upc.edu
[7]
http://listas.cimne.upc.edu/cgi-bin/mailman/listinfo/kratos
[8]
mailto:pooyan en cimne.upc.edu
[9] http://www.cimne.com/
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: http://listas.cimne.upc.edu/pipermail/kratos/attachments/20130621/b2f70d5a/attachment-0001.htm 


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