[Gfs-devel] Your opinion about a new source for migrations of species.

[Jose M. López-Herrera Sánchez]

Hi all,

I am thinking about to create a new source for tracers (VariableTracers & VariableVOFConcentration) to take into account  for example the electromigration of species. This is relevant for electrokinetic problems. The general equation for a charged specie, c, would be:

c_t + \nabla \cdot (c u) = nabla \cdot (K c E) + \nabla \cdot (D \nabla c)

where K is the conductivity of the specie.

Actually the electromigration term,   nabla \cdot  (K c E), can be taken into account as a diffusion-like using the fact that the electric field E = - \nabla \phi,

nabla \cdot (K c E) =  - nabla \cdot (K c \nabla \phi )

In a simulation file one therefore would write:  SourceDiffusionExplicit c K*c Phi 

However one could treat it like a advection-like term, i.e.

c_t + \nabla \cdot [c (u- KE)] =  \nabla \cdot (D \nabla c)

This would be the objective of the new source (I have in mind to name it SourceMigration for example).

Reasons for this new source? well, a couple,

    a) Sometimes the migration creates a travelling front that would be better treated by a Godunov type scheme.

    b) I have found that using the diffusion-like treatment  over VariableConcentrations one obtain unphysical situations like bulk negative concentrations (Concentrations has to be low-bounded to zero) I wonder if a vof advection-like treatment can avoid this.

To do this I am thinking to expand GfsFaceStateVector with a new gdouble element sv 

struct _GfsFaceStateVector {

  gdouble un;

  gdouble v;

  gdouble sv;

};

where to keep the normal electric field preserving the normal velocity, un.

I would be pleased if anyone has some feedback on this issue.

Cheers

Jose

[Daniel Fuster]

Hi Jose

> To do this I am thinking to expand GfsFaceStateVector with a new gdouble
> element sv
>
> struct _GfsFaceStateVector {
> gdouble un;
> gdouble v;
> gdouble sv;
> };

I do not think it is a good idea. Note that you will define a new
double x Ncells for every simulation (irrespective if you use your
object or not). From my personal experience and discussions with
Stephane, I would say that it is more convenient to define a new
variable. If you need the values at the faces, you will need to define
new variables that correspond to the value at the faces (an array of 4
dimensions in 2d and 6 dims in 3d). In my skewsymmetric module I do
that for the "skew" velocities.

best
Daniel

>
> where to keep the normal electric field preserving the normal velocity, un.
>
> I would be pleased if anyone has some feedback on this issue.
>
> Cheers
>
> Jose
>

> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_sfd2d_oct
> _______________________________________________
> Gfs-devel mailing list
> Gfs-...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gfs-devel
>



--
www.danielfuster.com

------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct
_______________________________________________
Gfs-devel mailing list
Gfs-...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gfs-devel

[Jose M. López-Herrera Sánchez]

Daniel, 

You are right, I will follow your advise. 

Cheers

Jose

2012/10/30 Daniel Fuster <dfu...@gmail.com>

[Jose M. López-Herrera Sánchez]

Hi all,

I have advanced on the coding of the new type of source (I have named it SourceAdvection) devoted to add a migration mechanism of species (Tracers) as an extra advection superposed to the regular velocity one. At the moment I have focused in the part of the vof advection (i.e. SourceAdvection applied to VariableVOFConcentrations)  with promising results (see figure). However the code  has something defective: If the SourceAdvection is applied to more than one tracer I got a segmentation fault  when I try to destroy  an array of GfsVariables. I am desperated stuck on this. Let me describe what I do:

The SourceAdvection has the folllowing form:

 struct _GfsSourceAdvection {

  /*< private >*/

  GfsSourceScalar parent;

  /*< public >*/

  GfsFunction * intensity;

  GfsVariable * e[FTT_DIMENSION];

  GfsVariable * vc[FTT_DIMENSION]; /* center values of the  migration velocity */

  GfsVariable * vn[FTT_NEIGHBORS]; /* face values of the migration velocity */

};

The extra-migration velocity center values, vc, and face values, vn, at mid time step are calculated  inside of  a source_advection_event ().  

Once I have available these values I have modified the gfs_tracer_vof_advection() in the following form:

1.- for each j->data concentration tracer:

   a) I create two array of variables  vcenter[FTT_DIMENSION] and vfaces[FTT_NEIGHBORS] by means of the gfs_temporary_variable (domain).

   b) Sum up all existing migration velocities provided by the SourceAdvections into the above variables arrays.

   c) since GFS_VARIABLE_TRACER (j->data)->advection.u and GFS_VARIABLE_TRACER (j->data)->advection.g are free hung up there the velocity arrays: 

         GFS_VARIABLE_TRACER (j->data)->advection.u = vcenter

         GFS_VARIABLE_TRACER (j->data)->advection.g = vfaces

  This is the point where I have more doubts. It is correct what I do in 1.c?

2.- for each j->data concentration tracer:

     a) Compute extra fluxdue to migration using the already calculated values stored at 

         GFS_VARIABLE_TRACER (j->data)->advection.u 

         GFS_VARIABLE_TRACER (j->data)->advection.g

3.-  for each j->data concentration tracer let destroy and restore:

          for (c...)

          if(GFS_VARIABLE_TRACER (j->data)->advection.u[c])

              gts_object_destroy .. ;

         GFS_VARIABLE_TRACER (j->data)->advection.u = NULL;

          for (d...)

          if(GFS_VARIABLE_TRACER (j->data)->advection.g[d])

              gts_object_destroy .. ;

         GFS_VARIABLE_TRACER (j->data)->advection.d = NULL;

It is here where the the program fails. Before going further  I want to solve it, maybe I am missing something obvious. 

I would appreciate any help on the issue.

Cheers

Jose

  

[Stephane Popinet]

Hi Jose,

> a) I create two array of variables vcenter[FTT_DIMENSION] and
> vfaces[FTT_NEIGHBORS] by means of the gfs_temporary_variable (domain).
> b) Sum up all existing migration velocities provided by the
> SourceAdvections into the above variables arrays.
> c) since GFS_VARIABLE_TRACER (j->data)->advection.u and
> GFS_VARIABLE_TRACER (j->data)->advection.g are free hung up there the
> velocity arrays:
> GFS_VARIABLE_TRACER (j->data)->advection.u = vcenter
> GFS_VARIABLE_TRACER (j->data)->advection.g = vfaces

How do you allocate the two arrays vcenter[] and vfaces[]? You need to
do something like:

GFS_VARIABLE_TRACER (j->data)->advection.u = vcenter = g_malloc
(FTT_DIMENSION*sizeof (GfsVariable *));

and then not forget to put the corresponding g_free() in the destroy method.

cheers

Stephane

------------------------------------------------------------------------------
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov

[Jose M. López-Herrera Sánchez]

Thanks for the tip, Stephane!

Cheers

Jose