[Kratos] proposing a list of "flags"

Riccardo Rossi rrossi en cimne.upc.edu
Jue Jun 20 16:44:31 CEST 2013


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, <jcotela en cimne.upc.edu> 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, <pooyan en cimne.upc.edu> 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, <jcotela en cimne.upc.edu> 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
>>>
>>>
>>>
>>
>>
>>
>>
>> --
>>
>> 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
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: http://listas.cimne.upc.edu/pipermail/kratos/attachments/20130620/cd2222b4/attachment-0001.htm 


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