[Kratos] proposing a list of "flags"

jcotela en cimne.upc.edu jcotela en cimne.upc.edu
Jue Jun 20 14:30:45 CEST 2013


  

Dear Riccardo, 

in my opinion, if we are concerned about this type
of problems, the solution should be throwing meaningful, human-readable
error messages, either at c++ or python-interface level (whichever is
simpler), instead of imposing arbitrary naming conventions and rules
which are hardly enforceable. As an aside, what happens if someone does
node.GetValue(FLAG)? That should be wrong too, if I understand your
proposal correctly. 

Jordi 

On Thu, 20 Jun 2013 14:15:03 +0200,
Riccardo Rossi wrote: 

> Dear Pooyan, Jordi,
> 
> the thing is that if
someone writes 
> node.Is(PRESSURE) 
> 
> he will get an error, without
any simple way to notice what he is doing it wrong. 
> 
> if you don't
like preprending the "f", which i do understand, why not postposing
"_FLAG"
> 
> node.Is(VISITED_FLAG)
> 
> Riccardo
> 
> On Thu, Jun 20,
2013 at 12:57 PM, wrote:
> 
>> 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]
>> 
>>
_______________________________________________
>> Kratos mailing
list
>> Kratos en listas.cimne.upc.edu [4]
>>
http://listas.cimne.upc.edu/cgi-bin/mailman/listinfo/kratos [5]
> 
> --

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

 

Links:
------
[1]
http://www.cimne.com/
[2] mailto:jcotela en cimne.upc.edu
[3]
http://www.cimne.com/
[4] mailto:Kratos en listas.cimne.upc.edu
[5]
http://listas.cimne.upc.edu/cgi-bin/mailman/listinfo/kratos
[6]
mailto:pooyan en cimne.upc.edu
[7] 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/324765c4/attachment-0001.htm 


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