[Kratos] proposing a list of "flags"

jcotela en cimne.upc.edu jcotela en cimne.upc.edu
Jue Jun 20 16:55:42 CEST 2013


  

Dear Riccardo, 

if node.GetValue(FLAG) is wrong, will it give a
runtime error or simply not compile? Will the runtime/compile error be
understandable? How is this situation different from the situation you
described (node.Is(PRESSURE) )? Can we make any/both of them to fail in
an "informative" way? 

On the issue of the names, then what happens
with the application-specific flags? Do they go to the general list of
flags? Will the application maintainer be responsible for choosing
"appropriate" names for application flags? That is basically what I'd
like to avoid. 

Jordi 

On Thu, 20 Jun 2013 16:44:31 +0200, Riccardo
Rossi wrote: 

> Dear Jordi,
> 
> node.GetValue(FLAG)
> 
> IS wrong
> 
>
furthermore enforcing the name is really easy since we need to decide a
list once and live with it...
> 
> Riccardo
> 
> On Thu, Jun 20, 2013 at
2:30 PM, wrote:
> 
>> 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]
>> 
>>
_______________________________________________
>> Kratos mailing
list
>> Kratos en listas.cimne.upc.edu [8]
>>
http://listas.cimne.upc.edu/cgi-bin/mailman/listinfo/kratos [9]
> 
> --

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

 

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/
[8]
mailto:Kratos en listas.cimne.upc.edu
[9]
http://listas.cimne.upc.edu/cgi-bin/mailman/listinfo/kratos
[10]
mailto:jcotela en cimne.upc.edu
[11] 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/78d8978a/attachment.htm 


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