[Gfs-devel] Local temporary children with no neighbor check

[Gael Guedon]

Hi all,

in order to implement a vertex-divergence projection filter, I would like to be able to compute values of temporary children to be able to deal with fine->coarse boundaries, though I am not sure yet if my approach is consistent...

Anyway, to accomplish this task I was thinking of something and I would like to have your feedback on this because I am not 100% sure of what are doing the functions I would like to use.

The temporary children will be created inside a cell traverse function so everything should be done locally.

Here is the sequence I am thinking of:

1) use ftt_cell_copy to copy the neighbor at a shallower level (at a fine->coarse boundary).

2) use a modified version of ftt_cell_refine_single on the newly created cell so that the check on neighbors is not performed (the new function could be called ftt_cell_refine_single_no_check)

3) get the value of the desired child (the variable should be initialized using gfs_cell_coarse_fine)

4) use ftt_cell_destroy to clean the temporary cell and its children

I looked inside the source for a similar function but I did not find anything except in vof.c. However there, a temporary refinement is performed on the whole domain which is not what I would like to obtain.

Any feedback is welcome!

Thank you very much for your help!

Cheers,

Gael

[Daniel Fuster]

Hi Gael

I am not sure to understand if you want to deal with fine->coarse
boundaries or not, but I feel that if you want to do this it would be
more difficult than the method you propose (I think it also concerns
communication when bc are applied). It is really a guess, not a
certitude...

In any case, for a different application, I also find it would be
useful to have a gboolean check_neighbors as an argument in
ftt_cell_refine_single, just as oct_new has. This would avoid to
create an extra function.

Best
Daniel

2012/11/12 Gael Guedon <gaelg...@gmail.com>:

> ------------------------------------------------------------------------------
> 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
> _______________________________________________
> Gfs-devel mailing list
> Gfs-...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gfs-devel
>



--
www.danielfuster.com

------------------------------------------------------------------------------
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
_______________________________________________
Gfs-devel mailing list
Gfs-...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gfs-devel

[Daniel Fuster]

I attach the patch from my version to allow for checking the
neighbors. It would be useful for me if you could use this patch for a
future implementation in the stable release (indeed I think the patch
could be implemented in the stable release right away if Stephane
agrees)

2012/11/13 Daniel Fuster <dfu...@gmail.com>:

www.danielfuster.com

[Gael Guedon]

Hi Daniel,

thank you very much for the quick reply!

I am not sure to understand if you want to deal with fine->coarse
boundaries or not

I would like to find a way to deal fine->coarse boundaries.

I think one solution is to ignore the filtering at fine->coarse

boundaries because coupling may be enough (since the mesh is

not uniform). However, I have absolutely no idea yet so I would like

to try some eventual solutions and compare them.

I feel that if you want to do this it would be
more difficult than the method you propose (I think it also concerns
communication when bc are applied). It is really a guess, not a
certitude...

I did not thought of this but I think you are right. For instance if

one wants to initialize the children of the neighbor, the gradient at the

neighbor need to be computed... one solution may be to compute the

gradients in a preliminary step... I see this possible issue as secondary.

For the moment, first order interpolation can be used at boundaries

(cf. gfs_cell_coarse_fine).

In any case, for a different application, I also find it would be
useful to have a gboolean check_neighbors as an argument in
ftt_cell_refine_single, just as oct_new has. This would avoid to
create an extra function.

I was thinking of this solution too.

I attach the patch from my version to allow for checking the
neighbors. It would be useful for me if you could use this patch for a
future implementation in the stable release (indeed I think the patch
could be implemented in the stable release right away if Stephane
agrees)

You are faster than me! Thank you for the patch, I will use it right now.

I also think it can be merged to the stable release without problem.

I have seen your post on "numerical integration" and I think you are

facing the same issue, i.e. temporary refinement/children without

interaction with neighbors.

I will keep you informed of any progress.

Cheers,

Gael

[Gael Guedon]

Hi Daniel,

When I apply the patch, darcs says that a previous patch is missing:

darcs failed:  Mon Sep 17 12:17:47 CEST 2012  Daniel Fuster <dfu...@gmail.com>
  * GfsInit allows for a physical end time

FATAL: Cannot apply this bundle. We are missing the above patches.

Maybe this patch also requires merging with the stable release..

Do you think I can apply the check_neighbors_in_refine_patch ignoring the previous patch ?

Thanks

Gael

PS: I should now be able to get the temporary refinement I wanted by applying a similar procedure as you did in GfsOutputErrorNormIntegration111312, you have been very helpful !

[Daniel Fuster]

Hi Gael

The patch was in this discussion
https://groups.google.com/forum/?fromgroups=#!topic/gerris-users/5fVr8rmXauc

For some reason it does not appear the link, so I attach it again. I
do not know if there is any reason why this patch was not applied. In
any case, it is my fault. I did not realize that I was doing the patch
againts a version that is not stable....

In your case, you can either apply both patches or just one, they are
completely independent

best
Daniel

2012/11/13 Gael Guedon <gaelg...@gmail.com>:

[Stephane Popinet]

Hi Gael,

> in order to implement a vertex-divergence projection filter, I would like to
> be able to compute values of temporary children to be able to deal with
> fine->coarse boundaries, though I am not sure yet if my approach is
> consistent...

If I understand correctly, what you would like to end up with is a
local regular Cartesian stencil on which you would apply the standard
vertex filtering algorithm. I don't think that creating then
destroying finer cells is the way to do this. It is going to be
complicated and expensive. I think that something similar to what is
done in vof.c is the right thing to do. You could easily modify the
stencil computation algorithm in vof.c to create regular stencils
around a vertex (rather than around the entire cell).

cheers

Stephane

[Stephane Popinet]

Hi Daniel,

> I attach the patch from my version to allow for checking the
> neighbors. It would be useful for me if you could use this patch for a
> future implementation in the stable release (indeed I think the patch
> could be implemented in the stable release right away if Stephane
> agrees)

Could you please explain why the check_neighbors option is useful in a
general sense? In the case of oct_new(), the only place I can see it
used is as part of ftt_cell_copy() which is itself not used anywhere
in the rest of Gerris (it looks like an obsolete function).

If this is really useful, I would rather have it as a new function, so
that the ftt.h interface is not broken (and changes to
ftt_reifne_single() everywhere are avoided).

cheers

Stephane

[Gael Guedon]

Hi Stephane,

If I understand correctly, what you would like to end up with is a
local regular Cartesian stencil on which you would apply the standard
vertex filtering algorithm.

This is exactly what I would like to do.

 

I don't think that creating then
destroying finer cells is the way to do this. It is going to be
complicated and expensive. I think that something similar to what is
done in vof.c is the right thing to do. You could easily modify the
stencil computation algorithm in vof.c to create regular stencils
around a vertex (rather than around the entire cell).

Thank you! I missed this function while looking for solutions...

I will definitely have a look and see if I can adjust it.

Do you think I can have issues with metric?

Cheers,

Gael

[Stephane Popinet]

> Do you think I can have issues with metric?

You should not worry too much about metric at this stage (VOF only
works without metric anyway for the moment). Filtering could also work
when applied only in computational space (i.e. without metric).

[Daniel Fuster]

Hi Stephane

> Could you please explain why the check_neighbors option is useful in a
> general sense?

I think you are right. Maybe it is not useful. Indeed I managed to
achieve my goal without changing this flag so I will leave the code as
it is.

>
> ------------------------------------------------------------------------------
> 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
> _______________________________________________
> Gfs-devel mailing list
> Gfs-...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gfs-devel

--
www.danielfuster.com