I have pushed again my patch for GfsOutputSpectra in my gerris-bubbles
repository. For now it does not work in parallel. Before doing that I
would like to have some small problems fixed:
1) I do not know how to destroy the object (I know it is simple but
what I do gives me segmentation fault...., for now I just do not
destroy the object)
2) I am not sure if the hierarchy I chose is the correct one. I have
derived GfsOutputSpectra2D and GfsOutputSpectra3D from a general class
called GfsOutputSpectra. Users should not be allowed to use directly
GfsOutputSpectra, where the dimension is not set. I do not know very
well how to avoid users to use GfsOutputSpectra.
If you feel it is fine, I will send you the parallel version (there
are also some minor issues we should discuss)
In any case, the current patch works already in serial. You can test
it with the following example:
GModule fft
1 1 GfsSimulation GfsBox GfsGEdge { } {
Time { iend = 1 dtmax = 1.e-4 }
Refine 7
GfsInit {} { U = sin(4.*M_PI*x)*cos(2.*M_PI*y)
V = -cos(4.*M_PI*x)*sin(2.*M_PI*y)
}
GfsOutputSpectra2D { istep = 1 } file-%ld.dat U { x=0 y=0 z=0
Lx=0.99 Ly=0.99 Lz=0 } 4
GfsOutputTime { istep =1 } stderr
}
GfsBox {
}
1 1 right
1 1 top
~
------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2dcopy2
_______________________________________________
Gfs-devel mailing list
Gfs-...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gfs-devel
Thanks for the code. I have a few questions/comments.
- I don't understand why you need OutputSpectra2D and OutputSpectra3D.
Do you plan on supporting 2D FTT for 3D problems?
- why does your write() method not write all the arguments that your
read() method reads?
- You do not allocate the CartesianGrid as a pointer to a
CartesianGrid object which is why you cannot destroy it using the
destroy method. The solution is to allocate it properly (as a pointer)
using gfs_cartesian_grid_new().
- could you please explain the meaning of the x,y,z and Lx,Ly,Lz arguments?
There are other minor changes I would like to make so please just
reply to these comments and I will make these changes myself.
cheers
Stephane
Thanks a lot for your comments.
> - I don't understand why you need OutputSpectra2D and OutputSpectra3D.
> Do you plan on supporting 2D FTT for 3D problems?
In principle I thought it would be a good idea to be able to do any
type of fft in 3D. I was planning even allow for 1D transform. I am
thinking now that maybe the best way to do this is to replace the { x
y z Lx Ly Lz } LEVEL syntax by a cartesian grid. This would allow
arbitrary dimension (from 1 to 3), tilted planed, etc. The new syntax
would be something like:
GfsOutputSpectra { istep = 1 } file-%ld.dat U cartesianinput.cgd
> - why does your write() method not write all the arguments that your
> read() method reads?
This is a bug. I changed my read and output subroutines but I
completely forgot about the writing method (sorry)
> - You do not allocate the CartesianGrid as a pointer to a
> CartesianGrid object which is why you cannot destroy it using the
> destroy method. The solution is to allocate it properly (as a pointer)
> using gfs_cartesian_grid_new().
Ok. If you agree with the modification I propose above I can try to
correct the problems of this patch and I will send you a new patch
> - could you please explain the meaning of the x,y,z and Lx,Ly,Lz arguments?
In principle (x,y,z) defines the center of the domain where the fft is
obtained and Lx,Ly,Lz are the lengths of the square (2D) or cube. I
think the syntax I propose above is more flexible.
> There are other minor changes I would like to make so please just
> reply to these comments and I will make these changes myself.
Thanks a lot. As I tell you, if you want I can try to send you first
an improved version of the module
best
Daniel
>
> cheers
>
> Stephane
>
> ------------------------------------------------------------------------------
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security
> threats, fraudulent activity, and more. Splunk takes this data and makes
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2dcopy2
> _______________________________________________
> Gfs-devel mailing list
> Gfs-...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gfs-devel
>
> In principle I thought it would be a good idea to be able to do any
> type of fft in 3D. I was planning even allow for 1D transform. I am
> thinking now that maybe the best way to do this is to replace the { x
> y z Lx Ly Lz } LEVEL syntax by a cartesian grid. This would allow
> arbitrary dimension (from 1 to 3), tilted planed, etc. The new syntax
> would be something like:
>
> GfsOutputSpectra { istep = 1 } file-%ld.dat U cartesianinput.cgd
That sounds llike a good idea, however I think that the CGD grid
should be optional and that the default could be to use a 2D/3D grid
(at the maximum resolution?). What do you think?
> Ok. If you agree with the modification I propose above I can try to
> correct the problems of this patch and I will send you a new patch
OK. Go ahead and I will merge your changes with mine.
cheers
Stephane
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
I have pushed the updated patch. Some comments:
1) I have merged all the objects in GfsOutputSpectra. It detects the
coordinates where the user wants to perform the fourier transform. I
allows for 1D fft. You will see I have modified several lines. I think
the changes are worthy but they can be annoying if you did a lot of
modification on top of my path.
2) Due to the new syntax I use the cgd as follows:
-I allocate the x,y,z coordinates even for 2D problems
-cgd->N only contains the number of dimensions of the fft
3) In GfsOutputSpectra->dir I store the directions that are computed
0 = x
1 = y
2 = z
If I want to compute a 2D fft in a YZ plane (example below)
dir=[1,2,0] (the last component is useless in this case)
4) I keep the previous syntax with x,y,z and Lx,Ly,Lz. It is hard to
me to imagine what should be the default behavior in complex domains
with several boxes. I have not implemented the possibility to include
a cgd mesh
5) I do not know how to find out the maximum level of refinement among
all the objects. For now the user has to specify it
6) I still get segmentation fault when I try to destroy the object. It
is funny because I am able to create it and destroy it in the same
subroutine. Definitely there is something I do not understand :(
I think that's all. If there is something unclear or you know how to
do things better just tell me. A 3D example is below
Thanks a lot
Daniel
GModule fft
1 3 GfsSimulation GfsBox GfsGEdge { } {
Time { iend = 1 dtmax = 1.e-4 }
Refine 5
GfsInit {} { U = sin(4.*M_PI*z)*cos(2.*M_PI*y)
V = -cos(4.*M_PI*z)*sin(2.*M_PI*y)
}
GfsOutputSpectra { istep = 1 } file-%ld.dat U { x=0. y=0. z=0.
Lx=0. Ly = 0.99 Lz = 0.99 } 4
GfsOutputSimulation { istep = 1 } sim.gfs {}
GfsOutputTime { istep =1 } stderr
}
GfsBox {
}
1 1 right
1 1 top
1 1 front
2011/9/26 Stephane Popinet <s.po...@niwa.co.nz>:
Thanks for the patches. I have made a number of minor changes. The
darcs patch is attached (somehow I couldn't push to gerris-bubbles on
patch-tag). Please have a look.
A few questions/comments:
- this loop looks weird:
ftt.mod:150: for ( l = 0; l < data->n3; l++ )
k.z = data->kmax.z*(gdouble) l;
it just ends up doing:
k.z = data->kmax.z*(gdouble) (data->n3 - 1);
- please be careful with indentation, useless extra characters, string
formatting, lines too long, compiler warnings etc...
> 5) I do not know how to find out the maximum level of refinement among
> all the objects. For now the user has to specify it
you can use gfs_domain_depth(). Maybe the level could be optional and
be set by default to gfs_domain_depth().
> 6) I still get segmentation fault when I try to destroy the object. It
> is funny because I am able to create it and destroy it in the same
> subroutine. Definitely there is something I do not understand :(
Seems to work fine for me. valgrind is hapy too. Please check.
- could you please write the doc for the module on the wiki?
cheers
Stephane
Thanks a lot for the corrections. I have pushed a couple of patches
fixing the line 150, and also a couple of things:
- I think I have to set GFS_OUTPUT_SPECTRA (o)->cgd->N = 3; in the
destroy method because I always allocate a 3D cartesian grid. However,
in cgd->N I just store the dimension of the fft.
- I have set the default values of L to zero. It is important because
I use L!=0 to set the dimensions (and directions) in which the fft is
applied. I have added a check in case all L == 0 (this is not allowed)
I will write the wiki today
best
Daniel
2011/9/28 Stephane Popinet <s.po...@niwa.co.nz>:
> - I think I have to set GFS_OUTPUT_SPECTRA (o)->cgd->N = 3; in the
> destroy method because I always allocate a 3D cartesian grid. However,
> in cgd->N I just store the dimension of the fft.
Hmm, I don't like this. You should not use cgd->N for storing
something else than what it is. This is asking for trouble. If you
need a variable to store the dimension of the fft, just add a new one
to GfsOutputSpectra. Please fix this.
> - I have set the default values of L to zero. It is important because
> I use L!=0 to set the dimensions (and directions) in which the fft is
> applied. I have added a check in case all L == 0 (this is not allowed)
Ok, apologies for introducing the bug.
> I will write the wiki today
Great thanks.
> Hmm, I don't like this. You should not use cgd->N for storing
> something else than what it is.
Ok. This is fixed in the new patch I have pushed in my repository. I
have also written the doc in the wiki
I have also looked the parallel version but I am afraid it is not
going to be possible. It just allow parallelization in one direction.
http://www.fftw.org/fftw3_doc/2d-MPI-example.html#2d-MPI-example
I could do something that works in specific cases but I do not see
the interest if it does not work for all cases. Maybe I should just
check the points inside the subdomain and perform several fft in
different subdomains.
Another option is to import the domain to proc 0 and to perform the
fft only in this proc.
Finally, the last option would be to redistribute the data in a way
that we could perform the parallel version of the fft, but I have a
lot of doubts about if this is really feasible.
best
Daniel
------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2dcopy2
> Ok. This is fixed in the new patch I have pushed in my repository. I
> have also written the doc in the wiki
Great thanks. I will push the patch for the next release.
There are a number of other patches I haven't pulled in your
gerris-bubbles repository i.e.
Sat Apr 23 05:29:28 NZST 2011 Daniel Fuster <dfu...@gmail.com>
* bugs in GfsBubbleFraction and GfsBubbleFractionDt
Shall I pull this patch? (1/12) [ynWsfvplxdaqjk], or ? for help: y
Sat Apr 23 06:10:46 NZST 2011 Daniel Fuster <dfu...@gmail.com>
* GfsParticleToDroplet object
Shall I pull this patch? (2/12) [ynWvplxdaqjk], or ? for help: y
Fri Apr 29 00:52:36 NZST 2011 "Gaurav Tomar" <gaurav....@gmail.com>
* GfsParticleToDroplet Object
Shall I pull this patch? (3/12) [ynWvplxdaqjk], or ? for help: y
Fri Apr 29 01:20:20 NZST 2011 "Gaurav Tomar" <gaurav....@gmail.com>
* Minor Bug Fix GfsParticleToDroplet
Shall I pull this patch? (4/12) [ynWsfvplxdaqjk], or ? for help: y
Fri Apr 29 01:50:38 NZST 2011 "Gaurav Tomar" <gaurav....@gmail.com>
* BugFix 2 ParticleToDroplet
Shall I pull this patch? (5/12) [ynWsfvplxdaqjk], or ? for help: y
Fri Apr 29 02:31:22 NZST 2011 Daniel Fuster <dfu...@gmail.com>
* minor changes in GfsParticleToDroplet
Shall I pull this patch? (6/12) [ynWvplxdaqjk], or ? for help: y
Wed Apr 27 02:26:22 NZST 2011 Daniel Fuster <dfu...@gmail.com>
* GfsBubbleInteractions object
Shall I pull this patch? (7/12) [ynWsfvplxdaqjk], or ? for help: y
Sat Apr 23 06:28:27 NZST 2011 Daniel Fuster <dfu...@gmail.com>
* bugs in GfsBubbleFraction and GfsBubbleFractionDt
Shall I pull this patch? (8/12) [ynWsfvplxdaqjk], or ? for help: y
Fri Apr 29 05:10:22 NZST 2011 Daniel Fuster <dfu...@gmail.com>
* tagging bubbles.mod
Shall I pull this patch? (9/12) [ynWsfvplxdaqjk], or ? for help: y
Mon Aug 1 20:47:37 NZST 2011 Daniel Fuster <dfu...@gmail.com>
* minor changes example
Shall I pull this patch? (10/12) [ynWsfvplxdaqjk], or ? for help: y
Mon Aug 1 20:55:46 NZST 2011 Daniel Fuster <dfu...@gmail.com>
* variable density in skew symmetric formulation
Shall I pull this patch? (11/12) [ynWvplxdaqjk], or ? for help: y
Mon Aug 8 03:23:30 NZST 2011 Daniel Fuster <dfu...@gmail.com>
* new scheme implementation based on the skew-symmetric formulation
Shall I pull this patch? (12/12) [ynWvplxdaqjk], or ? for help:
(Gaurav, if you read this, could you please give better descriptions
of your patches than e.g.
"BugFix 2 ParticleToDroplet").
Which of these patches should I pull?
cheers
Stephane
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
> There are a number of other patches I haven't pulled in your
> gerris-bubbles repository i.e.
I think you should not pull any of these patches.
Regarding bubbles, I still have the problem with the validation test
so I do not see the point in pulling the patches. I have been working
on that with Sumana and we find out that we do not get convergence for
pressure in the case where velocity converges. I will post it as soon
as I have the GfsOuputSpectra object completely finished (do you think
I should try to do a parallel version?)
Gaurav, are you implementing the last corrections Stephane suggested
in the particulate module? I could try to help with that if you are
very busy.
best
Daniel
I think before finishing my module in parallel you can already pull my
patch where I introduce in the serial version some syntax
modifications based on some Kristjan's suggestions. It is in my
repository and the name is:
Sat Oct 15 18:36:16 CEST 2011 Daniel Fuster <dfu...@gmail.com>
* Several improvements in the fft module
Now I use this syntax
GfsOutputSpectra { istep = 1 } file-%ld.dat U { x0=-0.5 y0=-0.5 z0=0.
x1=0.5 y1=0.5 z1=0 } 4
Basically I use the coordinates of the corners to define the domain
and then, the last number indicates the level of refinement in which
you want to obtain the fft. In case of AMR, it takes the minimum
between the user defined level and the minimum level of refinement for
all the cells contained inside the domain.
This is one example
GModule fft
1 1 GfsSimulation GfsBox GfsGEdge { } {
Time { iend = 2 dtmax = 1.e-4 }
Refine 5
GfsInit {} { U = sin(2.*M_PI*x)*cos(4.*M_PI*y)
V = -cos(2.*M_PI*x)*sin(4.*M_PI*y)
}
GfsOutputSpectra { istep = 1 } file-%ld.dat U { x0=-0.5 y0=-0.5
z0=0. x1=0.5 y1=0.5 z1=0 } 4
GfsOutputSimulation { istep = 1 } sim.gfs {}
GfsOutputTime { istep =1 } stderr
}
GfsBox {
}
1 1 right
1 1 top
2011/10/3 Daniel Fuster <dfu...@gmail.com>:
------------------------------------------------------------------------------
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn
about Cisco certifications, training, and career opportunities.
http://p.sf.net/sfu/cisco-dev2dev