[Kratos] proposing a list of "flags"

pooyan en cimne.upc.edu pooyan en cimne.upc.edu
Jue Jun 20 12:57:37 CEST 2013


  

Hi, 

About the compatibility the decision was taken because using
the flags is much faster than the other ones and giving the same
interface would give missleading guideline to the developers:


node.GetValue(PRESSURE) // VERY SLOW!!! 

node.GetValue(VISITED) //
VERY VERY FAST!!!!!  

so I decide to put it with different interfaces:


node.GetValue(PRESSURE) // VERY SLOW!!! 

node.Is(VISITED) // VERY
VERY FAST!!!!! 

So we can say that "Is" is faster than
"GetSolutionStepsValue" which is faster than "GetValue" 

About the flag
name I agree with Jordi, it is not easy to see and is not in the line
with our coding standard. And if a developer wants to use a flag he
knows if it is a flag or a variable, like he knows if it is vector or
scalar.  

About the FIX and Free I see the point of both of you and I
have to add that each flag also has a NOT_ one like: 

NOT_FIX


NOT_FREE 

and having both of them results in incompatibility while
NOT_FIX is not the same as FREE  

About the list of which variables,
this must be discussed in the meeting for this purpose and the email of
Riccardo is for saying to the people to start think about it and to
prepare the list of flags for each group so we can merge them together
in the meeting. Now the guideline here is that the name must be selected
in general forms with minimum application dependency. 

Bests, 

Pooyan.


On Thu, 20 Jun 2013 11:35:01 +0200, Riccardo Rossi wrote: 

> Dear
Jordi, the "flags" that are being developed will NOT be compatible with
the variable mechanisms, for this reason if we define a WALL flag we
will not be able to pass it into the existing databases.
> 
> for
example 
> node.GetSolutionStepValue( fFLAG ) 
> will NOT work since
fFLAG will be something different 
> 
> Exactly for this reason i
believe it would be important by simply looking at the name of the value
if it is a flag or a normal variable
> 
> having said this, if you have
a number of elements which by default are all active you may want to
"deactivate" some ... this was the reason for putting both ACTIVE and
DEACTIVATED.
> 
> regarding FIX and FREE i see your point ... but
imagine that one would like to mark one node so that all of its values
will be fixed ... maybe fBLOCKED could be a better option
> 
> having
said this, let's consider the list
> 
> 1 fACTIVE
> 2 fSLIP
> 3
fMASTER
> 4 fSLAVE
> 5 fERASE
> 6 fINTERFACE
> 7 fBOUNDARY
> 8
fMPI_BOUNDARY
> 9 fVISITED
> 10 fFLUID
> 11 fSTRUCTURE
> 12 fTHERMAL
>
13 fPERMANENT
> 14 fPROTECTED
> 15 fSPLIT
> 16 fMODIFIED
> 17 BLOCKED
>

> under discussion:
> fWALL
> 
> and let's use this as a basis for
further discussion
> 
> ciao
> Riccardo
> 
> On Thu, Jun 20, 2013 at
9:48 AM, wrote:
> 
>> Dear Riccardo, 
>> 
>> reading your mail, I have
several questions about the flags being proposed. As far as I know, some
of the flags in the list are application-specific, so I don't see why
they should go on the "general list", even if their equivalent variables
are in the main variables list (I'll speak for WALL, which is the only
one I'd use, but I suspect there are others). Also, ACTIVE ==
!(DEACTIVATED), FIX == !(FREE) why do we need them in pairs? Going back
to that last one, fixity in Kratos has a very specific meaning related
to Dofs, so I'd advise against using that name. 
>> 
>> As you probably
noticed by now, I'm strongly against the notation of fFLAG, just as we
don't write sTEMPERATURE or vVELOCITY. 
>> 
>> Greetings, 
>> 
>> Jordi

>> 
>> On Thu, 20 Jun 2013 09:12:25 +0200, Riccardo Rossi wrote: 
>>

>>> Dear All,
>>> in the near future, a mechanism shall be introduced
within Kratos to allow the use of "flags" (bool values) in a very
efficient manner.
>>> 
>>> The author of this is Pooyan, and i am sure
that when the feature is ready he will provide usage guidelines as well
as a description of the advanced features of the new flags.
>>> 
>>> as
a general consideration it will be needed to to define a limited number
of "general flags" which will be always present on all the elements
nodes and conditions of the kratos.
>>> This will be possible as many of
this values will be packed to a single double, which will allow
providing a very fast interface.
>>> The problem is that such list of
general flag will be "closed" so that it will not be possible to add or
change the list (I am sure Pooyan later on will explain
alternatives)
>>> 
>>> i would like to start a discussion on the name to
assign to such "general flags", putting here a list of the ones that
come to my mind.
>>> Please note that they SHOULD NOT be
application-specific!!
>>> 
>>> 1 fACTIVE
>>> 2 fDEACTIVATED
>>> 3
fSLIP
>>> 4 fMASTER
>>> 5 fSLAVE
>>> 6 fERASE
>>> 7 fINTERFACE
>>> 8
fBOUNDARY
>>> 9 fMPI_BOUNDARY
>>> 10 fVISITED
>>> 11 fFLUID
>>> 12
fSTRUCTURE
>>> 13 fTHERMAL
>>> 14 fPERMANENT
>>> 15 fPROTECTED
>>> 16
fWALL
>>> 17 fSPLIT
>>> 18 fMODIFIED
>>> 19 fFREE
>>> 20 fFIX
>>> 
>>>
the form of using it will be through a function "Is" to that the IS_ in
the name shall be removed
>>> 
>>> as you may observe i prepended to the
"flag name" an "f". This is my personal proposal to distinguish flags
from normal variables. 
>>> Other people suggest that it is not needed
to distinguish, so that the name shall be all capital as for normal
variables. 
>>> Please express your opinion also on the naming
convention to be used.
>>> 
>>> Aside of this please make proposals for
what should be added/removed from this list.
>>> 
>>> greetings from
BCN
>>> Riccardo
>>> 
>>> -- 
>>> 
>>> 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 [1]
> 
> -- 
> 
> 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 [3]

 

Links:
------
[1]
http://www.cimne.com/
[2] mailto:jcotela en cimne.upc.edu
[3]
http://www.cimne.com/
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: http://listas.cimne.upc.edu/pipermail/kratos/attachments/20130620/32048e76/attachment-0001.htm 


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