[Kratos] FLAGS -- Re: Resumen de Kratos, Vol 34, Envío 31

Josep Maria cpuigbo en cimne.upc.edu
Jue Jun 20 12:55:26 CEST 2013


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 this as a 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

---------------------



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






On 06/20/2013 11:35 AM, kratos-request en listas.cimne.upc.edu wrote:
> Envíe los mensajes para la lista Kratos a
> 	kratos en listas.cimne.upc.edu
>
> Para subscribirse o anular su subscripción a través de la WEB
> 	http://listas.cimne.upc.edu/cgi-bin/mailman/listinfo/kratos
>
> O por correo electrónico, enviando un mensaje con el texto "help" en
> el asunto (subject) o en el cuerpo a:
> 	kratos-request en listas.cimne.upc.edu
>
> Puede contactar con el responsable de la lista escribiendo a:
> 	kratos-owner en listas.cimne.upc.edu
>
> Si responde a algún contenido de este mensaje, por favor, edite la
> linea del asunto (subject) para que el texto sea mas especifico que:
> "Re: Contents of Kratos digest...". Además, por favor, incluya en la
> respuesta sólo aquellas partes del mensaje a las que está
> respondiendo.
>
>
> Asuntos del día:
>
>     1. proposing a list of "flags" (Riccardo Rossi)
>     2. Re: proposing a list of "flags" (jcotela en cimne.upc.edu)
>     3. Re: proposing a list of "flags" (Riccardo Rossi)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 20 Jun 2013 09:12:25 +0200
> From: Riccardo Rossi <rrossi en cimne.upc.edu>
> Subject: [Kratos] proposing a list of "flags"
> To: kratos <kratos en listas.cimne.upc.edu>
> Message-ID:
> 	<CAOVdALw5d=_y=70ct=bC9qw-hfd4RssAWMQozGJK1nzQxw24=w en mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> 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. 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

<mailto:%20cpuigbo en cimne.upc.edu>
	
	 CIMNE-UPC . Efidici C1, Campus Nord UPC . Gran Capitàn s/n . 08034 
Barcelona

------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: http://listas.cimne.upc.edu/pipermail/kratos/attachments/20130620/fb2f52f8/attachment.htm 


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