Re: cylindrical coordinates
Dear Daniel, Thanks for the reply. It is helpful to know about this. We have started working with the 3D Cartesian grid, first testing with a simple spherical diffusion problem for which an analytic solution exists. (We still make some use of symmetry, since we need to calculate only one octant of the solution...). The FiPy results agree really well with the analytic solution, and the calculation time is very acceptable for now. Best wishes, Martin On 10/10/2018 17:46, Daniel Wheeler wrote: > On Thu, Sep 20, 2018 at 4:15 AM Martinus WERTS > wrote: >> Now I would like to go 3D, and the symmetry of our system would allow to >> use a 2D cylindrical grid (r,z) - with zero flux at z=0 and z=L (and >> r=0), and either Dirichlet/zero flux at r=R. Looking at the mailing list >> archive and GitHub, it appears that cylindrical coordinates are at the >> moment not working properly (missing factor) > Yes, that's correct. Sorry about that. > >> Is this still the case? >> >> If so, I will start with a simple 3D Cartesian mesh, and then perhaps >> move to more adapted meshes, depending on the calculation speed and the >> precision required. Perhaps the cylindrical coordinates will be fixed in >> a near future? > Maybe, the developers of FiPy aren't doing an awful lot of work on it > so there is no timeline for fixing it. > >> Many thanks for any advice that you may have > Sorry that I can't be more helpful. > ___ fipy mailing list fipy@nist.gov http://www.ctcms.nist.gov/fipy [ NIST internal ONLY: https://email.nist.gov/mailman/listinfo/fipy ]
Re: cylindrical coordinates
On Thu, Sep 20, 2018 at 4:15 AM Martinus WERTS wrote: > > Now I would like to go 3D, and the symmetry of our system would allow to > use a 2D cylindrical grid (r,z) - with zero flux at z=0 and z=L (and > r=0), and either Dirichlet/zero flux at r=R. Looking at the mailing list > archive and GitHub, it appears that cylindrical coordinates are at the > moment not working properly (missing factor) Yes, that's correct. Sorry about that. > Is this still the case? > > If so, I will start with a simple 3D Cartesian mesh, and then perhaps > move to more adapted meshes, depending on the calculation speed and the > precision required. Perhaps the cylindrical coordinates will be fixed in > a near future? Maybe, the developers of FiPy aren't doing an awful lot of work on it so there is no timeline for fixing it. > Many thanks for any advice that you may have Sorry that I can't be more helpful. -- Daniel Wheeler ___ fipy mailing list fipy@nist.gov http://www.ctcms.nist.gov/fipy [ NIST internal ONLY: https://email.nist.gov/mailman/listinfo/fipy ]
cylindrical coordinates
Dear Fipy list, I am pretty much new to FiPy. I am using it to model the dynamic response of reaction-diffusion systems (particles/molecules diffusing to microelectrodes and then being captured/reacting). I had succes on a 2D Cartesian mesh (both Dirichlet and Neumann/zero flux boundary conditions). Now I would like to go 3D, and the symmetry of our system would allow to use a 2D cylindrical grid (r,z) - with zero flux at z=0 and z=L (and r=0), and either Dirichlet/zero flux at r=R. Looking at the mailing list archive and GitHub, it appears that cylindrical coordinates are at the moment not working properly (missing factor) Is this still the case? If so, I will start with a simple 3D Cartesian mesh, and then perhaps move to more adapted meshes, depending on the calculation speed and the precision required. Perhaps the cylindrical coordinates will be fixed in a near future? Many thanks for any advice that you may have Best wishes, Martin P.S. Thanks to all for the interesting discussions on the mailing list, and to the developers for this relatively accessible PDE solver package. ___ fipy mailing list fipy@nist.gov http://www.ctcms.nist.gov/fipy [ NIST internal ONLY: https://email.nist.gov/mailman/listinfo/fipy ]
AW: Gradient in cylindrical coordinates
This is great to know!! I will play around and see if it would work. I hope it is not much slower. Regards, Leyton -Ursprüngliche Nachricht- Von: fipy-boun...@nist.gov [mailto:fipy-boun...@nist.gov] Im Auftrag von Daniel Wheeler Gesendet: Montag, 8. Jänner 2018 19:58 An: Multiple recipients of list Betreff: Re: Gradient in cylindrical coordinates Also, note that the "leastSquaresGrad" doesn't have this issue: https://gist.github.com/wd15/fc34ccb2e57602fc6f9bea96d8160f4a#file-untitled-ipynb See, https://www.ctcms.nist.gov/fipy/fipy/generated/fipy.variables.html#fipy.variables.cellVariable.CellVariable.leastSquaresGrad On Mon, Jan 8, 2018 at 1:39 PM, Daniel Wheeler wrote: > Hi Leyton, > > I think there is an error in FiPy when calculating gradients with > cylindrical grids. FiPy assumes that the cylindrical faces don't count > towards the face contributions, but they do. It needs to be fixed. It > results in a systematic error of "phi / r". I'll try and fix this in > the near future. Sorry about that. > > For further details see, > > https://gist.github.com/wd15/fc34ccb2e57602fc6f9bea96d8160f4a#file-unt > itled-ipynb > > I've very roughly outlined the problem at the bottom of the notebook > and a better discretization. A quick fix right now would be to use a > 3D slice rather than the cylindrical grid. I'm not sure how much this > impacts other calculations with cylindrical grids in FiPy. > > I also put this in an issue. Please do add comments if you have ideas. > > https://github.com/usnistgov/fipy/issues/547 > > Thanks for reporting this. > > Cheers, > > Daniel > > > On Fri, Jan 5, 2018 at 7:23 PM, Munoz Leyton > wrote: >> Dear Fipy Team, >> >> >> >> First of all I would like to thank you for your amazing work! I love >> working with fipy. >> >> >> >> I have a problem when I calculate the gradient of my variable in >> cylindrical coordinates. You can see the code I used below this line. >> >> >> >> from fipy import * >> >> from fipy import CellVariable, FaceVariable, Grid2D, TransientTerm, \ >> >> UpwindConvectionTerm, DiffusionTerm, ImplicitSourceTerm, >> CylindricalGrid2D >> >> >> >> L = 89e-3 # m >> >> diameterChamber = 13.75e-3 >> >> radius = diameterChamber/2 >> >> dz = 1e-3 >> >> dr = 0.75e-3 >> >> nz = round(L/dz) >> >> nr = round(radius/dr) >> >> #mesh = Grid2D(dx=dx, nx=nx, dy=dy, ny=ny) >> >> mesh = CylindricalGrid2D(dz=dz, nz=nz, dr=dr, nr=nr) >> >> >> >> pressure_0 = CellVariable(mesh=mesh, name='Pressure Gas', hasOld=1) >> >> pressure_0.setValue(1e5) >> >> pressure_0.grad.value >> >> >> >> The pressure is constant all over the domain so I would expect the >> gradient to be zero. just as it is in Cartesian coordinates. But I get this: >> >> >> >> array([[ 2666.6667, 888.8889, 533., ..., >> >> 205.12820513, 177.7778, 156.8627451 ], >> >>[0., 0., 0., ..., >> >> 0., 0., 0.]]) >> >> >> >> Could you please help me? Am I doing something wrong? is it a bug? >> >> >> >> I would like also to contribute to the community with an example of >> compressible flow with euler equations in 2D Cartesian coordinates. I >> validated the results with SOD shock tube and I was quite happy with it. >> With whom should I talk to review it and possibly upload it? >> >> >> >> Kind regards, >> >> Leyton >> >> >> >> ACHTUNG neue e-Mail Adresse: vorname.nachn...@hirtenberger.com >> Nachrichten an die alte E-Mail Adresse werden vorübergehend auf die >> neue Adresse umgeleitet. >> >> ATTENTION new e-mail address: vorname.nachn...@hirtenberger.com >> Messages to the old address are temporarily redirected to the new address. >> >> >> >> P Bitte prüfen Sie der Umwelt zuliebe, ob der Ausdruck dieser Mail >> erforderlich ist. / Please consider your environmental responsibility >> before printing this email. >> >> >> >> Diese Nachricht und allfaellige angehaengte Dokumente sind >> vertraulich und nur für den/die Adressaten bestimmt. Sollten Sie >> nicht der beabsichtigte Adressat sein, ist jede Offenlegung, >> Weiterleitung oder sonstige Verwendung dieser Informati
Re: Gradient in cylindrical coordinates
Leyton - A compressible flow example contribution would be most welcome! Please submit a [pull request](https://github.com/usnistgov/fipy/pulls) and we'll work with you to get it integrated and released. [don't hesitate to ask if you need help making the pull request] - Jon > On Jan 5, 2018, at 7:23 PM, Munoz Leyton > wrote: > > I would like also to contribute to the community with an example of > compressible flow with euler equations in 2D Cartesian coordinates. I > validated the results with SOD shock tube and I was quite happy with it. With > whom should I talk to review it and possibly upload it? > ___ fipy mailing list fipy@nist.gov http://www.ctcms.nist.gov/fipy [ NIST internal ONLY: https://email.nist.gov/mailman/listinfo/fipy ]
Re: Gradient in cylindrical coordinates
Also, note that the "leastSquaresGrad" doesn't have this issue: https://gist.github.com/wd15/fc34ccb2e57602fc6f9bea96d8160f4a#file-untitled-ipynb See, https://www.ctcms.nist.gov/fipy/fipy/generated/fipy.variables.html#fipy.variables.cellVariable.CellVariable.leastSquaresGrad On Mon, Jan 8, 2018 at 1:39 PM, Daniel Wheeler wrote: > Hi Leyton, > > I think there is an error in FiPy when calculating gradients with > cylindrical grids. FiPy assumes that the cylindrical faces don't count > towards the face contributions, but they do. It needs to be fixed. It > results in a systematic error of "phi / r". I'll try and fix this in > the near future. Sorry about that. > > For further details see, > > https://gist.github.com/wd15/fc34ccb2e57602fc6f9bea96d8160f4a#file-untitled-ipynb > > I've very roughly outlined the problem at the bottom of the notebook > and a better discretization. A quick fix right now would be to use a > 3D slice rather than the cylindrical grid. I'm not sure how much this > impacts other calculations with cylindrical grids in FiPy. > > I also put this in an issue. Please do add comments if you have ideas. > > https://github.com/usnistgov/fipy/issues/547 > > Thanks for reporting this. > > Cheers, > > Daniel > > > On Fri, Jan 5, 2018 at 7:23 PM, Munoz Leyton > wrote: >> Dear Fipy Team, >> >> >> >> First of all I would like to thank you for your amazing work! I love working >> with fipy. >> >> >> >> I have a problem when I calculate the gradient of my variable in cylindrical >> coordinates. You can see the code I used below this line. >> >> >> >> from fipy import * >> >> from fipy import CellVariable, FaceVariable, Grid2D, TransientTerm, \ >> >> UpwindConvectionTerm, DiffusionTerm, ImplicitSourceTerm, >> CylindricalGrid2D >> >> >> >> L = 89e-3 # m >> >> diameterChamber = 13.75e-3 >> >> radius = diameterChamber/2 >> >> dz = 1e-3 >> >> dr = 0.75e-3 >> >> nz = round(L/dz) >> >> nr = round(radius/dr) >> >> #mesh = Grid2D(dx=dx, nx=nx, dy=dy, ny=ny) >> >> mesh = CylindricalGrid2D(dz=dz, nz=nz, dr=dr, nr=nr) >> >> >> >> pressure_0 = CellVariable(mesh=mesh, name='Pressure Gas', hasOld=1) >> >> pressure_0.setValue(1e5) >> >> pressure_0.grad.value >> >> >> >> The pressure is constant all over the domain so I would expect the gradient >> to be zero. just as it is in Cartesian coordinates. But I get this: >> >> >> >> array([[ 2666.6667, 888.8889, 533., ..., >> >> 205.12820513, 177.7778, 156.8627451 ], >> >>[0., 0., 0., ..., >> >> 0., 0., 0.]]) >> >> >> >> Could you please help me? Am I doing something wrong? is it a bug? >> >> >> >> I would like also to contribute to the community with an example of >> compressible flow with euler equations in 2D Cartesian coordinates. I >> validated the results with SOD shock tube and I was quite happy with it. >> With whom should I talk to review it and possibly upload it? >> >> >> >> Kind regards, >> >> Leyton >> >> >> >> ACHTUNG neue e-Mail Adresse: vorname.nachn...@hirtenberger.com Nachrichten >> an die alte E-Mail Adresse werden vorübergehend auf die neue Adresse >> umgeleitet. >> >> ATTENTION new e-mail address: vorname.nachn...@hirtenberger.com Messages to >> the old address are temporarily redirected to the new address. >> >> >> >> P Bitte prüfen Sie der Umwelt zuliebe, ob der Ausdruck dieser Mail >> erforderlich ist. / Please consider your environmental responsibility before >> printing this email. >> >> >> >> Diese Nachricht und allfaellige angehaengte Dokumente sind vertraulich und >> nur für den/die Adressaten bestimmt. Sollten Sie nicht der beabsichtigte >> Adressat sein, ist jede Offenlegung, Weiterleitung oder sonstige Verwendung >> dieser Information nicht gestattet. In diesem Fall bitten wir, den Absender >> zu verstaendigen und die Information zu vernichten. Für Uebermittlungsfehler >> oder sonstige Irrtuemer bei der Uebermittlung besteht keine Haftung. >> >> This message and any attached files are confidential and intended solely for >> the addressee(s). Any publication, transmission or other use of the >> information by a person or entity other than the intended addressee is >> prohibited. If you receive this in error please contact the sender and >> delete the material. The sender does not accept liability for any errors or >> missions as a result of the transmission. Please destroy this message and >> notify the sender. >> >> >> ___ >> fipy mailing list >> fipy@nist.gov >> http://www.ctcms.nist.gov/fipy >> [ NIST internal ONLY: https://email.nist.gov/mailman/listinfo/fipy ] >> > > > > -- > Daniel Wheeler -- Daniel Wheeler ___ fipy mailing list fipy@nist.gov http://www.ctcms.nist.gov/fipy [ NIST internal ONLY: https://email.nist.gov/mailman/listinfo/fipy ]
Re: Gradient in cylindrical coordinates
Hi Leyton, I think there is an error in FiPy when calculating gradients with cylindrical grids. FiPy assumes that the cylindrical faces don't count towards the face contributions, but they do. It needs to be fixed. It results in a systematic error of "phi / r". I'll try and fix this in the near future. Sorry about that. For further details see, https://gist.github.com/wd15/fc34ccb2e57602fc6f9bea96d8160f4a#file-untitled-ipynb I've very roughly outlined the problem at the bottom of the notebook and a better discretization. A quick fix right now would be to use a 3D slice rather than the cylindrical grid. I'm not sure how much this impacts other calculations with cylindrical grids in FiPy. I also put this in an issue. Please do add comments if you have ideas. https://github.com/usnistgov/fipy/issues/547 Thanks for reporting this. Cheers, Daniel On Fri, Jan 5, 2018 at 7:23 PM, Munoz Leyton wrote: > Dear Fipy Team, > > > > First of all I would like to thank you for your amazing work! I love working > with fipy. > > > > I have a problem when I calculate the gradient of my variable in cylindrical > coordinates. You can see the code I used below this line. > > > > from fipy import * > > from fipy import CellVariable, FaceVariable, Grid2D, TransientTerm, \ > > UpwindConvectionTerm, DiffusionTerm, ImplicitSourceTerm, > CylindricalGrid2D > > > > L = 89e-3 # m > > diameterChamber = 13.75e-3 > > radius = diameterChamber/2 > > dz = 1e-3 > > dr = 0.75e-3 > > nz = round(L/dz) > > nr = round(radius/dr) > > #mesh = Grid2D(dx=dx, nx=nx, dy=dy, ny=ny) > > mesh = CylindricalGrid2D(dz=dz, nz=nz, dr=dr, nr=nr) > > > > pressure_0 = CellVariable(mesh=mesh, name='Pressure Gas', hasOld=1) > > pressure_0.setValue(1e5) > > pressure_0.grad.value > > > > The pressure is constant all over the domain so I would expect the gradient > to be zero. just as it is in Cartesian coordinates. But I get this: > > > > array([[ 2666.6667, 888.8889, 533., ..., > > 205.12820513, 177.7778, 156.8627451 ], > >[0., 0., 0., ..., > > 0., 0., 0.]]) > > > > Could you please help me? Am I doing something wrong? is it a bug? > > > > I would like also to contribute to the community with an example of > compressible flow with euler equations in 2D Cartesian coordinates. I > validated the results with SOD shock tube and I was quite happy with it. > With whom should I talk to review it and possibly upload it? > > > > Kind regards, > > Leyton > > > > ACHTUNG neue e-Mail Adresse: vorname.nachn...@hirtenberger.com Nachrichten > an die alte E-Mail Adresse werden vorübergehend auf die neue Adresse > umgeleitet. > > ATTENTION new e-mail address: vorname.nachn...@hirtenberger.com Messages to > the old address are temporarily redirected to the new address. > > > > P Bitte prüfen Sie der Umwelt zuliebe, ob der Ausdruck dieser Mail > erforderlich ist. / Please consider your environmental responsibility before > printing this email. > > > > Diese Nachricht und allfaellige angehaengte Dokumente sind vertraulich und > nur für den/die Adressaten bestimmt. Sollten Sie nicht der beabsichtigte > Adressat sein, ist jede Offenlegung, Weiterleitung oder sonstige Verwendung > dieser Information nicht gestattet. In diesem Fall bitten wir, den Absender > zu verstaendigen und die Information zu vernichten. Für Uebermittlungsfehler > oder sonstige Irrtuemer bei der Uebermittlung besteht keine Haftung. > > This message and any attached files are confidential and intended solely for > the addressee(s). Any publication, transmission or other use of the > information by a person or entity other than the intended addressee is > prohibited. If you receive this in error please contact the sender and > delete the material. The sender does not accept liability for any errors or > missions as a result of the transmission. Please destroy this message and > notify the sender. > > > ___ > fipy mailing list > fipy@nist.gov > http://www.ctcms.nist.gov/fipy > [ NIST internal ONLY: https://email.nist.gov/mailman/listinfo/fipy ] > -- Daniel Wheeler ___ fipy mailing list fipy@nist.gov http://www.ctcms.nist.gov/fipy [ NIST internal ONLY: https://email.nist.gov/mailman/listinfo/fipy ]
Gradient in cylindrical coordinates
Dear Fipy Team, First of all I would like to thank you for your amazing work! I love working with fipy. I have a problem when I calculate the gradient of my variable in cylindrical coordinates. You can see the code I used below this line. from fipy import * from fipy import CellVariable, FaceVariable, Grid2D, TransientTerm, \ UpwindConvectionTerm, DiffusionTerm, ImplicitSourceTerm, CylindricalGrid2D L = 89e-3 # m diameterChamber = 13.75e-3 radius = diameterChamber/2 dz = 1e-3 dr = 0.75e-3 nz = round(L/dz) nr = round(radius/dr) #mesh = Grid2D(dx=dx, nx=nx, dy=dy, ny=ny) mesh = CylindricalGrid2D(dz=dz, nz=nz, dr=dr, nr=nr) pressure_0 = CellVariable(mesh=mesh, name='Pressure Gas', hasOld=1) pressure_0.setValue(1e5) pressure_0.grad.value The pressure is constant all over the domain so I would expect the gradient to be zero. just as it is in Cartesian coordinates. But I get this: array([[ 2666.6667, 888.8889, 533., ..., 205.12820513, 177.7778, 156.8627451 ], [0., 0., 0., ..., 0., 0., 0.]]) Could you please help me? Am I doing something wrong? is it a bug? I would like also to contribute to the community with an example of compressible flow with euler equations in 2D Cartesian coordinates. I validated the results with SOD shock tube and I was quite happy with it. With whom should I talk to review it and possibly upload it? Kind regards, Leyton ACHTUNG neue e-Mail Adresse: vorname.nachn...@hirtenberger.com<mailto:vorname.nachn...@hirtenberger.com> Nachrichten an die alte E-Mail Adresse werden vor?bergehend auf die neue Adresse umgeleitet. ATTENTION new e-mail address: vorname.nachn...@hirtenberger.com<mailto:vorname.nachn...@hirtenberger.com> Messages to the old address are temporarily redirected to the new address. P Bitte pr?fen Sie der Umwelt zuliebe, ob der Ausdruck dieser Mail erforderlich ist. / Please consider your environmental responsibility before printing this email. Diese Nachricht und allfaellige angehaengte Dokumente sind vertraulich und nur f?r den/die Adressaten bestimmt. Sollten Sie nicht der beabsichtigte Adressat sein, ist jede Offenlegung, Weiterleitung oder sonstige Verwendung dieser Information nicht gestattet. In diesem Fall bitten wir, den Absender zu verstaendigen und die Information zu vernichten. F?r Uebermittlungsfehler oder sonstige Irrtuemer bei der Uebermittlung besteht keine Haftung. This message and any attached files are confidential and intended solely for the addressee(s). Any publication, transmission or other use of the information by a person or entity other than the intended addressee is prohibited. If you receive this in error please contact the sender and delete the material. The sender does not accept liability for any errors or missions as a result of the transmission. Please destroy this message and notify the sender. ___ fipy mailing list fipy@nist.gov http://www.ctcms.nist.gov/fipy [ NIST internal ONLY: https://email.nist.gov/mailman/listinfo/fipy ]
Re: 2D Cylindrical Coordinates - Pipe
The "Volume" for a 2D mesh is the area of the cell. The "Volume" for a 1D mesh isthe length of the cell. > > The CylindricalGrid2D represents a wedge that subtends 1 rad. > Ah, I see now. Thank you for the clarification! For what I want to do, I have actually found that the following few lines of code gave me what I need: x, y = mesh.getCellCenters() inner_radii = x - (dx / 2) outer_radii = x + (dx / 2) That way I can use the radial coordinates for a few different purposes throughout my script. Maybe this is too simple..? But it seems to give me exactly what I want right now. Thank you, again for all your help and patience with beginners like myself! ___ fipy mailing list fipy@nist.gov http://www.ctcms.nist.gov/fipy [ NIST internal ONLY: https://email.nist.gov/mailman/listinfo/fipy ]
Re: 2D Cylindrical Coordinates - Pipe
On Jun 20, 2012, at 11:20 AM, Kendall Boniface wrote: > I'm a bit confused about the getCellVolumes() function. Since I am using the > 2D cylindrical grid, I assume it isn't actually giving me "volumes" so to > speak. I've manually played around with some of my numbers and can't seem to > figure out what the numbers I get from getCellVolumes() actually represent. > Can you clarify that for me? The "Volume" for a 2D mesh is the area of the cell. The "Volume" for a 1D mesh is the length of the cell. The CylindricalGrid2D represents a wedge that subtends 1 rad. ___ fipy mailing list fipy@nist.gov http://www.ctcms.nist.gov/fipy [ NIST internal ONLY: https://email.nist.gov/mailman/listinfo/fipy ]
Re: 2D Cylindrical Coordinates - Pipe
On Tue, Jun 19, 2012 at 1:04 PM, Jonathan Guyer wrote: > > On Jun 19, 2012, at 12:20 PM, Kendall Boniface wrote: > > > I am having a bit of trouble manipulating a 2D cylindrical mesh and was > wondering if anyone has any helpful advice? > > > > mesh = CylindricalGrid2D(dx=dx, dy=dy, nx=nx, ny=ny) + ((0.0046,),) > > print mesh.getCellCenters() > > > > I want the z axis to go from 0 to 1.5 > > The second term in the mesh line seems to translate the r AND z > coordinates outward when all I want it to do is translate the r > coordinates. Is there a way to do this the way I would like? > > The displacement should be a vector. You're trying to translate a 2D mesh > by a 1D vector. As it happens, NumPy interprets that to mean displacing the > r and z coordinates by the same amount, but what you want is > > mesh = CylindricalGrid2D(dx=dx, dy=dy, nx=nx, ny=ny) + ((0.0046,),(0.,)) > > Thank you Jonathan, that works perfectly. > > > Is there a way to access the radial distances from the origin for every > cell? That isn't the best way to word the question, but to make it more > clear, I would like to be able to do something like: pi * (r_outer**2 - > r_inner**2) for each cell. I have tried as many of the mesh.get functions > as I could get my hands on, but haven't been successful yet. Can anyone > suggest something for me to use? > > A mesh.getFaceCenters()[..., mesh._getCellFaceIDs()] would get you an > array of the coordinates of the faces for each cell. You'd probably have to > do something with mesh._getFaceNormals() to figure out which are the > "inner" and "outer" faces. > > For the actual calculation you present, though, it seems like > mesh.getCellVolumes() is what you want. > I'm a bit confused about the getCellVolumes() function. Since I am using the 2D cylindrical grid, I assume it isn't actually giving me "volumes" so to speak. I've manually played around with some of my numbers and can't seem to figure out what the numbers I get from getCellVolumes() actually represent. Can you clarify that for me? Thank you very much for for all your help! Kendall ___ fipy mailing list fipy@nist.gov http://www.ctcms.nist.gov/fipy [ NIST internal ONLY: https://email.nist.gov/mailman/listinfo/fipy ]
Re: 2D Cylindrical Coordinates - Pipe
On Jun 19, 2012, at 12:20 PM, Kendall Boniface wrote: > I am having a bit of trouble manipulating a 2D cylindrical mesh and was > wondering if anyone has any helpful advice? > mesh = CylindricalGrid2D(dx=dx, dy=dy, nx=nx, ny=ny) + ((0.0046,),) > print mesh.getCellCenters() > > I want the z axis to go from 0 to 1.5 > The second term in the mesh line seems to translate the r AND z coordinates > outward when all I want it to do is translate the r coordinates. Is there a > way to do this the way I would like? The displacement should be a vector. You're trying to translate a 2D mesh by a 1D vector. As it happens, NumPy interprets that to mean displacing the r and z coordinates by the same amount, but what you want is mesh = CylindricalGrid2D(dx=dx, dy=dy, nx=nx, ny=ny) + ((0.0046,),(0.,)) > Is there a way to access the radial distances from the origin for every cell? > That isn't the best way to word the question, but to make it more clear, I > would like to be able to do something like: pi * (r_outer**2 - r_inner**2) > for each cell. I have tried as many of the mesh.get functions as I could get > my hands on, but haven't been successful yet. Can anyone suggest something > for me to use? A mesh.getFaceCenters()[..., mesh._getCellFaceIDs()] would get you an array of the coordinates of the faces for each cell. You'd probably have to do something with mesh._getFaceNormals() to figure out which are the "inner" and "outer" faces. For the actual calculation you present, though, it seems like mesh.getCellVolumes() is what you want. ___ fipy mailing list fipy@nist.gov http://www.ctcms.nist.gov/fipy [ NIST internal ONLY: https://email.nist.gov/mailman/listinfo/fipy ]
2D Cylindrical Coordinates - Pipe
Hello again, I am having a bit of trouble manipulating a 2D cylindrical mesh and was wondering if anyone has any helpful advice? I want a mesh that is 1.5 meters in the z direction and has an inner radius of 0.0046 m and an outer radius of 0.00635 m (to model the wall of a pipe). This is what I have so far but it isn't quite right: from fipy import * z = 1.5 r_inner = 0.0046 r_outer = 0.00635 nx = 10 ny = 20 dx = (r_outer - r_inner) / nx dy = z / ny mesh = CylindricalGrid2D(dx=dx, dy=dy, nx=nx, ny=ny) + ((0.0046,),) print mesh.getCellCenters() I want the z axis to go from 0 to 1.5 The second term in the mesh line seems to translate the r AND z coordinates outward when all I want it to do is translate the r coordinates. Is there a way to do this the way I would like? My other question is this: Is there a way to access the radial distances from the origin for every cell? That isn't the best way to word the question, but to make it more clear, I would like to be able to do something like: pi * (r_outer**2 - r_inner**2) for each cell. I have tried as many of the mesh.get functions as I could get my hands on, but haven't been successful yet. Can anyone suggest something for me to use? Thank you very much in advance, Kendall ___ fipy mailing list fipy@nist.gov http://www.ctcms.nist.gov/fipy [ NIST internal ONLY: https://email.nist.gov/mailman/listinfo/fipy ]
Re: 3D Transient Conduction - Cylindrical Coordinates
On Tue, Jun 5, 2012 at 1:08 PM, Kendall Boniface
wrote:
>
> Hi Daniel,
> I have set the edge lengths to 1 and placed the gmsh commands in a .geo file
> as you suggested. I've attached the .geo file to this message. I also
> removed the 4 lines and the last line of the gmsh commands as I think they
> may not be required.
How will gmsh know the values of the "r" and "R" parameters?
> This is the error I get when I run the resulting code:
>
> "Traceback (most recent call last):
> File "C:\Users\SL\Documents\Python27\Gmsh Stuff\3DCylinder.py", line 8, in
>
> mesh = GmshImporter3D("pipe.geo")
> File "C:\Program
> Files\Python27\lib\site-packages\fipy-2.1.3-py2.7.egg\fipy\meshes\numMesh\gmshImport.py",
> line 454, in __init__
> mesh.Mesh.__init__(self, **_DataGetter(mshfile.getFilename(),
> dimensions=3).getData())
> File "C:\Program
> Files\Python27\lib\site-packages\fipy-2.1.3-py2.7.egg\fipy\meshes\numMesh\gmshImport.py",
> line 196, in getData
> vertexCoords = self._calcVertexCoords(self.coordDimensions)
> File "C:\Program
> Files\Python27\lib\site-packages\fipy-2.1.3-py2.7.egg\fipy\meshes\numMesh\gmshImport.py",
> line 253, in _calcVertexCoords
> maxNode = max(nodeToVertexIDdict.keys())
> ValueError: max() arg is an empty sequence"
I was actually indicating that you can run the geo file with gmsh
directly, independent from fipy or python. Load a geo file into gmsh
with
$ gmsh file.geo
at the command line. It'll throw up the GUI so you can inspect the geometry.
Commenting out sections from the file and loading into gmsh
demonstrated that "Line Loop(23)" has a "-7", which isn't a line.
That's where the problem seems to lie.
Cheers
--
Daniel Wheeler
___
fipy mailing list
fipy@nist.gov
http://www.ctcms.nist.gov/fipy
[ NIST internal ONLY: https://email.nist.gov/mailman/listinfo/fipy ]
Re: 3D Transient Conduction - Cylindrical Coordinates
> I pasted the gmsh commands into a file and ran gmsh on it. It threw a
> weird error
>
> ** On entry to DGESVD parameter number 6 had an illegal value
>
> What error did you get? Did you adapt the gmsh commands from
> somewhere? Maybe we could work from that and check that those commands
> work correctly. Googling the error indicates that it has something to
> do with the tolerance for recombination. Try rescaling the problem so
> the edge lengths are close to 1. Also cut and paste the gmsh commands
> into a geo file and run that against gmsh rather than using fipy
> making it easier to debug.
Hi Daniel,
I have set the edge lengths to 1 and placed the gmsh commands in a .geo
file as you suggested. I've attached the .geo file to this message. I also
removed the 4 lines and the last line of the gmsh commands as I think they
may not be required.
This is the error I get when I run the resulting code:
"Traceback (most recent call last):
File "C:\Users\SL\Documents\Python27\Gmsh Stuff\3DCylinder.py", line 8,
in
mesh = GmshImporter3D("pipe.geo")
File "C:\Program
Files\Python27\lib\site-packages\fipy-2.1.3-py2.7.egg\fipy\meshes\numMesh\gmshImport.py",
line 454, in __init__
mesh.Mesh.__init__(self, **_DataGetter(mshfile.getFilename(),
dimensions=3).getData())
File "C:\Program
Files\Python27\lib\site-packages\fipy-2.1.3-py2.7.egg\fipy\meshes\numMesh\gmshImport.py",
line 196, in getData
vertexCoords = self._calcVertexCoords(self.coordDimensions)
File "C:\Program
Files\Python27\lib\site-packages\fipy-2.1.3-py2.7.egg\fipy\meshes\numMesh\gmshImport.py",
line 253, in _calcVertexCoords
maxNode = max(nodeToVertexIDdict.keys())
ValueError: max() arg is an empty sequence"
Point(1) = {0, 0, 0, cl};
Point(2) = {R, 0, 0, cl};
Point(3) = {0, R, 0, cl};
Point(4) = {-R, 0, 0, cl};
Point(5) = {0, -R, 0, cl};
Point(6) = {r, 0, 0, cl};
Point(7) = {0, r, 0, cl};
Point(8) = {-r, 0, 0, cl};
Point(9) = {0, -r, 0, cl};
Circle(11) = {3,1,4};
Circle(12) = {4,1,5};
Circle(13) = {5,1,2};
Circle(14) = {2,1,3};
Circle(15) = {7,1,8};
Circle(16) = {8,1,9};
Circle(17) = {9,1,6};
Circle(18) = {6,1,7};
Line(19) = {7,3};
Line(20) = {9,5};
Line Loop(21) = {19,11,12,-20,-16,-15};
Plane Surface(22) = {21};
Line Loop(23) = {20,13,14,-19,-18,-7};
Plane Surface(24) = {23};
Transfinite Line{11:18} = 6/2;
Transfinite Line{19,20} = 6;
Transfinite Surface{22,24} = {23,24,22,21};
Recombine Surface '*';
Extrude{0,0,length}{Surface{22,24}; Layers{4,1}; Recombine};
___
fipy mailing list
fipy@nist.gov
http://www.ctcms.nist.gov/fipy
[ NIST internal ONLY: https://email.nist.gov/mailman/listinfo/fipy ]
Re: 3D Transient Conduction - Cylindrical Coordinates
On Mon, Jun 4, 2012 at 2:01 PM, Kendall Boniface wrote: > I have tried to set up a 3D mesh using Gmsh, but have not been very > successful. Could anyone offer some insight as to how I can set this up > successfully? I pasted the gmsh commands into a file and ran gmsh on it. It threw a weird error ** On entry to DGESVD parameter number 6 had an illegal value What error did you get? Did you adapt the gmsh commands from somewhere? Maybe we could work from that and check that those commands work correctly. Googling the error indicates that it has something to do with the tolerance for recombination. Try rescaling the problem so the edge lengths are close to 1. Also cut and paste the gmsh commands into a geo file and run that against gmsh rather than using fipy making it easier to debug. -- Daniel Wheeler ___ fipy mailing list fipy@nist.gov http://www.ctcms.nist.gov/fipy [ NIST internal ONLY: https://email.nist.gov/mailman/listinfo/fipy ]
3D Transient Conduction - Cylindrical Coordinates
Hello again,
First of all, thank you for your help with my previous problem.
I have been building on the problem and have run into some trouble in
defining a more complex geometry.
Here is a quick overview:
I am still looking at the transient conduction through a material where the
thermal conductivity of that material changes as a function of the
temperature. My previous post was just looking at a simple 1D problem (just
straight conduction through a slab of the material). Now I would like to
look at it in 3D cylindrical coordinates. We have an insulated 1.5m long
pipe with an inner and outer radius of 0.0046m and 0.00635m respectively.
So I am only concerned with what happens between these radii, not with
anything from the inner radius to the center of the pipe.
I have tried to set up a 3D mesh using Gmsh, but have not been very
successful. Could anyone offer some insight as to how I can set this up
successfully?
Thank you very much in advance for your help!
###
from fipy import *
# 3D Cylindrical Mesh in Gmsh
# Is there a cylindrical 3D mesh option for FiPy that might be easier to
use?
r = 0.0023 # inner radius of pipe
R = 0.003175# outer radius of pipe
length = 1.5 # length of test section (z coordinate)
cl = 0.0001 # characteristic length
mesh = GmshImporter3D('''
r = %(r)g; # are the first 4 lines here
necessary?
R = %(R)g;
length = %(length)g;
cl = %(cl)g;
Point(1) = {0, 0, 0, cl};
Point(2) = {R, 0, 0, cl};
Point(3) = {0, R, 0, cl};
Point(4) = {-R, 0, 0, cl};
Point(5) = {0, -R, 0, cl};
Point(6) = {r, 0, 0, cl};
Point(7) = {0, r, 0, cl};
Point(8) = {-r, 0, 0, cl};
Point(9) = {0, -r, 0, cl};
Circle(11) = {3,1,4};
Circle(12) = {4,1,5};
Circle(13) = {5,1,2};
Circle(14) = {2,1,3};
Circle(15) = {7,1,8};
Circle(16) = {8,1,9};
Circle(17) = {9,1,6};
Circle(18) = {6,1,7};
Line(19) = {7,3};
Line(20) = {9,5};
# The following was adapted from an example I found where you
make 2 surfaces on the cross section of the
# pipe (shaped like a C and a backwards C), then connect and
extrude them
# Is that a common way to do something like this?
Line Loop(21) = {19,11,12,-20,-16,-15};
Plane Surface(22) = {21};
Line Loop(23) = {20,13,14,-19,-18,-7};
Plane Surface(24) = {23};
Transfinite Line{11:18} = 6/2;
Transfinite Line{19,20} = 6;
Transfinite Surface{22,24} = {23,24,22,21};
Recombine Surface '*';
Extrude{0,0,length}{Surface{22,24}; Layers{4,1}; Recombine};
''' % locals()) # I am not 100% sure what the
purpose of 'locals' is. Is it needed?
# Definitions:
omega = 0.00164
k0 = 11.83
temp = CellVariable(name = 'Temperature', mesh=mesh, hasOld=1)
therm_cond = k0 * numerix.exp(omega * temp)
therm_cond.name = 'Thermal Conductivity'
# Boundary Conditions
rFlux = [100]
RFlux = [0]
rTemp = 150
RTemp = 250
BCs = (FixedFlux(faces=mesh.getExteriorFaces(), value=RFlux),\ # is
this the correct way to represent the
# outer radius BCs?
FixedValue(faces=mesh.getInteriorFaces(), value=rTemp),)#
and the inner radius ones?
eq = TransientTerm() == DiffusionTerm(coeff=therm_cond)
# Solving equation
elapsedTime = 0
totalElapsedTime = 300
timeStep = 1
desiredResidual = 0.0001
if __name__ == '__main__':
Tviewer = Viewer(vars=temp)
kviewer = Viewer(vars=therm_cond)
meshviewer = Viewer(vars=temp)
meshviewer.plot() # I would really like to be able to view the
mesh on its own to satisfy myself that it is
# exactly how I want it
# I don't think this method is correct,
could you suggest a better way?
while elapsedTime < totalElapsedTime:
temp.updateOld()
residual = 1e100
while residual > desiredResidual:
residual = eq.sweep(var=temp, boundaryConditions=BCs, dt=timeStep)
elapsedTime += timeStep
# Plot results:
if __name__ == '__main__':
Tviewer.plot()
kviewer.plot()
___
fipy mailing list
fipy@nist.gov
http://www.ctcms.nist.gov/fipy
[ NIST internal ONLY: https://email.nist.gov/mailman/listinfo/fipy ]
Re: ... cylindrical coordinates ...
On Jan 19, 2007, at 10:51 PM, Matt Koch wrote: Rejected message: sent to fipy@nist.gov by [EMAIL PROTECTED] follows. Reason for rejection: sender not subscribed. --- Hi Jonathan, I have to deal with both a cylinder and a sheet geometry. I think in order for me to make progress, I'll switch from cylinder to sheet, which should be doable in rectangular coordinates without too much fuss. That way, I can focus on what really matters, i.e. implementing level set Stefan problems in solidification (EFG). I'll start messing with that now. I am sure there'll be plenty of questions as I get into this. If I can solve it suceesfully, though, it'll give me the confidence that it is worth tackling the cylinder coordinates in 3D later on. Thanks again for your help thus far - I am sure we'll pick up on this again after some success with the rectangular coordinates. Note that the level set algorithms are only implemented in 1D and 2D as yet. -- Daniel Wheeler
Re: ... cylindrical coordinates ...
Hi Jonathan, oops, I am sorry, I forgot that I am loosing the "scitex.us" association when I use web mail. Here goes again. Regards, Matt Koch Jonathan Guyer wrote: Matt, I don't know if you get notification, but this message got bounced. Please resend from your scitex.us address, or subscribe the other one; whichever is easier. Thanks, - Jon On Jan 18, 2007, at 10:29 PM, fipy@nist.gov wrote: Rejected message: sent to fipy@nist.gov by [EMAIL PROTECTED] follows. Reason for rejection: sender not subscribed. --- Hi Jonathan, I have to deal with both a cylinder and a sheet geometry. I think in order for me to make progress, I'll switch from cylinder to sheet, which should be doable in rectangular coordinates without too much fuss. That way, I can focus on what really matters, i.e. implementing level set Stefan problems in solidification (EFG). I'll start messing with that now. I am sure there'll be plenty of questions as I get into this. If I can solve it suceesfully, though, it'll give me the confidence that it is worth tackling the cylinder coordinates in 3D later on. Thanks again for your help thus far - I am sure we'll pick up on this again after some success with the rectangular coordinates. Regards, Matt Koch Jonathan Guyer wrote: On Jan 18, 2007, at 2:24 PM, Matt Koch wrote: thanks for the quick feedback. So, if I am not too mistaken, I might as well view this like modelling a slice of pie in cartesian (rectangular) 3D space, and applying zero flux, etc., boundary conditions to the two flanks (planes of constant theta) of the slice? Exactly. We really are talking about a 3D model then. No need to talk about cylindrical coordinates then, simply model an arbitrary shape (such as a cylinder) in rectangular 3D space? Not exactly. The slice of pie will only be one cell deep. It's only a sliver of pie, not a whole slice. The question then is, how well will a mesh approximate curved surfaces? Right, that's a question. Naively, you'd think that you should make the sliver as thin as possible, so that the difference between the chord length and the arc length is negligibly small, but I seem to remember Daniel telling me that it's not that simple. We do think that it's possible to lie to the mesh so that it thinks that its faces are curved, but we'll have to test that. Plus, no matter how thin the slice in 3D, a computational sacrifice has to be made, because we are dealing with more grid points in 3D than we would in 2D? Am I getting close, or have I missed the point? There's some cost, but not huge. FiPy only evaluates your fields on cell centers, and you'll have exactly as many cell centers as if you did things in 2D. The cells will be cuboids in 3D instead of squares in 2D, so there's a bit of extra computation needed for that, but it shouldn't be too bad.
Re: ... cylindrical coordinates ...
On Jan 18, 2007, at 2:24 PM, Matt Koch wrote: thanks for the quick feedback. So, if I am not too mistaken, I might as well view this like modelling a slice of pie in cartesian (rectangular) 3D space, and applying zero flux, etc., boundary conditions to the two flanks (planes of constant theta) of the slice? Exactly. We really are talking about a 3D model then. No need to talk about cylindrical coordinates then, simply model an arbitrary shape (such as a cylinder) in rectangular 3D space? Not exactly. The slice of pie will only be one cell deep. It's only a sliver of pie, not a whole slice. The question then is, how well will a mesh approximate curved surfaces? Right, that's a question. Naively, you'd think that you should make the sliver as thin as possible, so that the difference between the chord length and the arc length is negligibly small, but I seem to remember Daniel telling me that it's not that simple. We do think that it's possible to lie to the mesh so that it thinks that its faces are curved, but we'll have to test that. Plus, no matter how thin the slice in 3D, a computational sacrifice has to be made, because we are dealing with more grid points in 3D than we would in 2D? Am I getting close, or have I missed the point? There's some cost, but not huge. FiPy only evaluates your fields on cell centers, and you'll have exactly as many cell centers as if you did things in 2D. The cells will be cuboids in 3D instead of squares in 2D, so there's a bit of extra computation needed for that, but it shouldn't be too bad.
Re: ... cylindrical coordinates ...
Jonathan, Daniel, thanks for the quick feedback. So, if I am not too mistaken, I might as well view this like modelling a slice of pie in cartesian (rectangular) 3D space, and applying zero flux, etc., boundary conditions to the two flanks (planes of constant theta) of the slice? We really are talking about a 3D model then. No need to talk about cylindrical coordinates then, simply model an arbitrary shape (such as a cylinder) in rectangular 3D space? The question then is, how well will a mesh approximate curved surfaces? Plus, no matter how thin the slice in 3D, a computational sacrifice has to be made, because we are dealing with more grid points in 3D than we would in 2D? Am I getting close, or have I missed the point? Regards, Matt Jonathan Guyer wrote: On Jan 18, 2007, at 11:13 AM, Daniel Wheeler wrote: On Jan 17, 2007, at 4:12 PM, Matt Koch wrote: I just have no concept of why I would need a 3D mesh to generate a 2D cylindrical mesh. This is so that the cell volumes and face areas are approximated correctly. You could of course subclass from Grid2D to make a CylindricalGrid2D object and overwrite the methods required to create cell volumes and face areas. I am not sure if this is all you have to do, but I suspect it is. Just in case we're not all thinking the same thing when we say "2D" and "3D" in this case, I'm going to attempt to clarify (but will probably fail miserably). Let's take our cylindrical coordinates to be r: radial distance from axis of cylinder theta: azimuthal angle around axis of cylinder z: distance along length of cylinder It is a simple matter to map these three coordinates to the Cartesian coordinates X, Y, Z. Matt originally said he wanted (r, z), making the common assumption of axial symmetry. Although (r,z) can be trivially mapped to (x,z), FiPy's divergence operator will not give the correct result, because it operates in Cartesian coordinates and will give (\partial \phi_x / \partial x) instead of (1/r)(\partial (r \phi_r) / \partial r). In theory, we could come up with a new discretization for the cylindrical operator, but this wouldn't be fun at all. Instead, by making a wedge (slice of pie) in X, Y, Z, we should automatically get a pretty good approximation of the cylindrical operator, because the areas of the faces and the volumes of the cells would be changing with the radius, and this gets reflected in the Cartesian discretization. We think that we could do an even better job by adjusting the face areas and cell volumes to account for the fact that the inner and outer faces are curved. We will probably do this at some stage and it may not be such a big job, but I can't do it right now. The stages for doing this are as follows. 1) Create class CylindricalGird2D subclassed from UniformGrid2D. 2) Overwrite getCellVolumes(), getFaceAreas() to have the correct values. The idea here is that as long as we're fudging the face areas and cell volumes in a 3D wedge mesh, we might as well fudge the face "areas" and cell "volumes" of a 2D mesh. This will require much testing, but should work. This is something that has now come up a couple of times on the list and which is going to be useful for some of our own research, so we will be working on a canned solution, but I can't say how long it will take. Actually creating a wedge mesh wouldn't be too hard at all, but validation will take some time. There are questions like is it better to have fixed radial spacing or is it better to have the cell spacing drop off as 1/r or ???. In addition, if you wanted to look at a problem with axial symmetry and no z variation (just r in a plane), then it should be possible adapt a UniformGrid1D in the same basic way, but again, this would all have to be validated. 3) Tee Geometry Thanks for the tip. I recall now having stumbled across this somewhere in the documentation. I assume the "shift and merge" trick somehow applies to the above cylindrical mesh as well? Yes, that works in 3D and would work if you created a CylindricalGrid2D object as well. Just be aware that the algorithm isn't particularly fancy. The exterior faces of the different mesh pieces that merge together have to coincide with each other. FiPy won't try to fix things up if they don't.
Re: ... cylindrical coordinates ...
On Jan 18, 2007, at 11:13 AM, Daniel Wheeler wrote: On Jan 17, 2007, at 4:12 PM, Matt Koch wrote: I just have no concept of why I would need a 3D mesh to generate a 2D cylindrical mesh. This is so that the cell volumes and face areas are approximated correctly. You could of course subclass from Grid2D to make a CylindricalGrid2D object and overwrite the methods required to create cell volumes and face areas. I am not sure if this is all you have to do, but I suspect it is. Just in case we're not all thinking the same thing when we say "2D" and "3D" in this case, I'm going to attempt to clarify (but will probably fail miserably). Let's take our cylindrical coordinates to be r: radial distance from axis of cylinder theta: azimuthal angle around axis of cylinder z: distance along length of cylinder It is a simple matter to map these three coordinates to the Cartesian coordinates X, Y, Z. Matt originally said he wanted (r, z), making the common assumption of axial symmetry. Although (r,z) can be trivially mapped to (x,z), FiPy's divergence operator will not give the correct result, because it operates in Cartesian coordinates and will give (\partial \phi_x / \partial x) instead of (1/r)(\partial (r \phi_r) / \partial r). In theory, we could come up with a new discretization for the cylindrical operator, but this wouldn't be fun at all. Instead, by making a wedge (slice of pie) in X, Y, Z, we should automatically get a pretty good approximation of the cylindrical operator, because the areas of the faces and the volumes of the cells would be changing with the radius, and this gets reflected in the Cartesian discretization. We think that we could do an even better job by adjusting the face areas and cell volumes to account for the fact that the inner and outer faces are curved. We will probably do this at some stage and it may not be such a big job, but I can't do it right now. The stages for doing this are as follows. 1) Create class CylindricalGird2D subclassed from UniformGrid2D. 2) Overwrite getCellVolumes(), getFaceAreas() to have the correct values. The idea here is that as long as we're fudging the face areas and cell volumes in a 3D wedge mesh, we might as well fudge the face "areas" and cell "volumes" of a 2D mesh. This will require much testing, but should work. This is something that has now come up a couple of times on the list and which is going to be useful for some of our own research, so we will be working on a canned solution, but I can't say how long it will take. Actually creating a wedge mesh wouldn't be too hard at all, but validation will take some time. There are questions like is it better to have fixed radial spacing or is it better to have the cell spacing drop off as 1/r or ???. In addition, if you wanted to look at a problem with axial symmetry and no z variation (just r in a plane), then it should be possible adapt a UniformGrid1D in the same basic way, but again, this would all have to be validated. 3) Tee Geometry Thanks for the tip. I recall now having stumbled across this somewhere in the documentation. I assume the "shift and merge" trick somehow applies to the above cylindrical mesh as well? Yes, that works in 3D and would work if you created a CylindricalGrid2D object as well. Just be aware that the algorithm isn't particularly fancy. The exterior faces of the different mesh pieces that merge together have to coincide with each other. FiPy won't try to fix things up if they don't.
Re: ... cylindrical coordinates ...
On Jan 17, 2007, at 4:12 PM, Matt Koch wrote: Hi Daniel, and thanks for your quick response. Here is my response in return: 1) Installation I used Enthought's Pyhon 2.4 and the straight downloads of PyVTK-0.47 (?) and FiPy-1.1 from your web site to install on Windows 2000. I also added PySparse-0.34. Somehow, I can't shake the feeling that the whole thing is quite unstable - the system seems to lock up on many of the example problems, but then again, I just realized that may be because calculations are running in the background which make the Phython interface freeze up. Plus, I only have 512 MB of memory on a AMD XP 1700+. The IDLE interface is forever locking up on me too. This could be more to do with my machine, but I am not sure. I don't use Windows very much. Mostly I just check that thinks work on Windows and leave it at that. I have thought about recommending a better IDE on Windows, but haven't got round to checking any. IDLE comes with enthought python so it seems like the obvious choice. I know that ipython has been used effectively on Windows. You may want to look into this: <http://ipython.scipy.org/moin/FrontPage> <http://showmedo.com/videos/series?name=PythonIPythonSeries> Also, there seem to be dozens of IDEs for python wiki.python.org/moin/IntegratedDevelopmentEnvironments>. On Slackware 10.2 Linux, I downloaded all the "tar.gz" packages from various places (it comes with Python 2.4 pre-installed) and used the "python setup.py build" and/or "python setup.py install" procedures. The matplotlib-0.87 (?) library seems to contain a bug, so I had to SVN that one. After that, it seems to work. I did not put MayaVI on yet, but I might, just to compare Windows 2000 and Linux on a one on one basis. I wouldn't bother with Mayavi unless you find that you need it for some reason. We may well stop supporting it soon as it has become outdated and matplotlib is fairly ubiquitous in teh scientific python community now as well as possibly getting support for 3D. 2) Wedge-Shaped Mesh Is there a document where I can read up on this? No. We have no examples as yet. I just have no concept of why I would need a 3D mesh to generate a 2D cylindrical mesh. This is so that the cell volumes and face areas are approximated correctly. You could of course subclass from Grid2D to make a CylindricalGrid2D object and overwrite the methods required to create cell volumes and face areas. I am not sure if this is all you have to do, but I suspect it is. Do I need a 3D mesh to generate a 2D rectangular mesh as well? No. 2D mesh objects are really 2D. The reason you would have to do it in the case of cylindrical coordinates it to avoid making changes to the discretization of the equations. I believe (needs to be confirmed) that changing the cell volumes and face areas does in fact allow you to use cartesian discretization with cylindrical coordinates. As far as my approach, while I like GMsh a lot, if I can get done what I need to get done in FiPy, all the better. So, perhaps you can provide some assistance with a 2D cylindrical mesh generated in FiPy alone? We will probably do this at some stage and it may not be such a big job, but I can't do it right now. The stages for doing this are as follows. 1) Create class CylindricalGird2D subclassed from UniformGrid2D. 2) Overwrite getCellVolumes(), getFaceAreas() to have the correct values. 3) Write some test cases. By "wedge-shaped", do you mean as in a slice of pie? Exactly. 3) Tee Geometry Thanks for the tip. I recall now having stumbled across this somewhere in the documentation. I assume the "shift and merge" trick somehow applies to the above cylindrical mesh as well? Yes, that works in 3D and would work if you created a CylindricalGrid2D object as well. Cheers Best Regards, Matt Koch Daniel Wheeler wrote: Hi Matt, Thanks for your interest. I'll try and answer your questions below. On Jan 16, 2007, at 11:23 PM, Matt Koch wrote: Hello there, I am brand new new FiPy, in fact just seem to have managed to install it on Windows 2000 and Slackware 10.2 Linux. Good. Did you use subversion to get the latest version of fipy or did you install 1.1? This seems like enormously powerful software! I have read some documentation and briefly reviewed the mailing list. There is one entry (http://www.mail-archive.com/fipy@nist.gov/msg00116.html) that seems to speak to the subject, but it is a little too advanced for me. This exchange discusses wedge shaped meshes that are a requirement for faking cylindrical coordinates using Cartesian discretization. If you want to solve a 2D cylindrical problem, you need to create a 3D wedge shaped mesh. This may be possible in gmsh and then you can use the Gmsh importer
Re: ... cylindrical coordinates ...
Hi Daniel, and thanks for your quick response. Here is my response in return: 1) Installation I used Enthought's Pyhon 2.4 and the straight downloads of PyVTK-0.47 (?) and FiPy-1.1 from your web site to install on Windows 2000. I also added PySparse-0.34. Somehow, I can't shake the feeling that the whole thing is quite unstable - the system seems to lock up on many of the example problems, but then again, I just realized that may be because calculations are running in the background which make the Phython interface freeze up. Plus, I only have 512 MB of memory on a AMD XP 1700+. On Slackware 10.2 Linux, I downloaded all the "tar.gz" packages from various places (it comes with Python 2.4 pre-installed) and used the "python setup.py build" and/or "python setup.py install" procedures. The matplotlib-0.87 (?) library seems to contain a bug, so I had to SVN that one. After that, it seems to work. I did not put MayaVI on yet, but I might, just to compare Windows 2000 and Linux on a one on one basis. 2) Wedge-Shaped Mesh Is there a document where I can read up on this? I just have no concept of why I would need a 3D mesh to generate a 2D cylindrical mesh. Do I need a 3D mesh to generate a 2D rectangular mesh as well? As far as my approach, while I like GMsh a lot, if I can get done what I need to get done in FiPy, all the better. So, perhaps you can provide some assistance with a 2D cylindrical mesh generated in FiPy alone? By "wedge-shaped", do you mean as in a slice of pie? 3) Tee Geometry Thanks for the tip. I recall now having stumbled across this somewhere in the documentation. I assume the "shift and merge" trick somehow applies to the above cylindrical mesh as well? Best Regards, Matt Koch Daniel Wheeler wrote: Hi Matt, Thanks for your interest. I'll try and answer your questions below. On Jan 16, 2007, at 11:23 PM, Matt Koch wrote: Hello there, I am brand new new FiPy, in fact just seem to have managed to install it on Windows 2000 and Slackware 10.2 Linux. Good. Did you use subversion to get the latest version of fipy or did you install 1.1? This seems like enormously powerful software! I have read some documentation and briefly reviewed the mailing list. There is one entry (http://www.mail-archive.com/fipy@nist.gov/msg00116.html) that seems to speak to the subject, but it is a little too advanced for me. This exchange discusses wedge shaped meshes that are a requirement for faking cylindrical coordinates using Cartesian discretization. If you want to solve a 2D cylindrical problem, you need to create a 3D wedge shaped mesh. This may be possible in gmsh and then you can use the Gmsh importer to read the mesh and run it in fipy. We can discuss this further if this is what you decide on doing. You may also be able to bury the cylindrical prefactors inside the term's coefficient. I would have to look more closely at your equations. I am just wondering how to set up a problem in cylindrical (r,z) rather than rectangular (x,y) coordinates. Is there a command I should call or is there an object I have to initialize in order to switch on cylindrical coordinates? From the above entry, I am almost guessing that one would have to implement their own divergences and such in cylindrical coordinates by adding the radius in proper places of the divergences and such in rectangular coordinates? That can't be right!? The wedge shaped mesh will take care of this, although there is some loss of accuracy. I have never measured the error, but I have been informed that this is an acceptable method. I think refactoring the discretization and various gradient operators for cylindrical coordinates would be quite an involved process at this point and I wouldn't recommend it. Also, other than using GMsh (which is incredibly awesome software, by the way), how I can I create somewhat more complicated domains than the simple lines, squares and circles used in most of the examples. Can I generate such geometry in FiPy, and can I mesh that then? All I have seen thus far is meshing commands for lines, rectangles or circles. How would I create and mesh, say, a Tee shape? You can splice meshes in fipy, which is more straightforward than using gmsh for some problems. To create a T mesh, you need just create two rectangular meshes and add them together as below. Remember the vertices and faces have to be perfectly aligned and not overlapping >>> from fipy import * >>> mesh1 = Grid2D(nx=6, ny=2) + (-3.0, 6.0) >>> mesh2 = Grid2D(nx=2, ny=6) >>> mesh = mesh1 + mesh2 >>> print mesh.getCellCenters() [[-2.5 6.5] [-1.5 6.5] [-0.5 6.5] [ 0.5 6.5] [ 1.5 6.5] [ 2.5 6.5] [-2.5 7.5] [-1.5 7.5] [-0.5 7.5] [ 0.5 7.5] [ 1.5 7.5] [ 2.5 7.5] [ 0.5 0.5] [ 1.5 0.5] [ 0.5 1.5] [ 1.5 1.5] [ 0.5 2.5] [ 1.5 2
Re: ... cylindrical coordinates ...
Hi Matt, Thanks for your interest. I'll try and answer your questions below. On Jan 16, 2007, at 11:23 PM, Matt Koch wrote: Hello there, I am brand new new FiPy, in fact just seem to have managed to install it on Windows 2000 and Slackware 10.2 Linux. Good. Did you use subversion to get the latest version of fipy or did you install 1.1? This seems like enormously powerful software! I have read some documentation and briefly reviewed the mailing list. There is one entry (http://www.mail-archive.com/fipy@nist.gov/msg00116.html) that seems to speak to the subject, but it is a little too advanced for me. This exchange discusses wedge shaped meshes that are a requirement for faking cylindrical coordinates using Cartesian discretization. If you want to solve a 2D cylindrical problem, you need to create a 3D wedge shaped mesh. This may be possible in gmsh and then you can use the Gmsh importer to read the mesh and run it in fipy. We can discuss this further if this is what you decide on doing. You may also be able to bury the cylindrical prefactors inside the term's coefficient. I would have to look more closely at your equations. I am just wondering how to set up a problem in cylindrical (r,z) rather than rectangular (x,y) coordinates. Is there a command I should call or is there an object I have to initialize in order to switch on cylindrical coordinates? From the above entry, I am almost guessing that one would have to implement their own divergences and such in cylindrical coordinates by adding the radius in proper places of the divergences and such in rectangular coordinates? That can't be right!? The wedge shaped mesh will take care of this, although there is some loss of accuracy. I have never measured the error, but I have been informed that this is an acceptable method. I think refactoring the discretization and various gradient operators for cylindrical coordinates would be quite an involved process at this point and I wouldn't recommend it. Also, other than using GMsh (which is incredibly awesome software, by the way), how I can I create somewhat more complicated domains than the simple lines, squares and circles used in most of the examples. Can I generate such geometry in FiPy, and can I mesh that then? All I have seen thus far is meshing commands for lines, rectangles or circles. How would I create and mesh, say, a Tee shape? You can splice meshes in fipy, which is more straightforward than using gmsh for some problems. To create a T mesh, you need just create two rectangular meshes and add them together as below. Remember the vertices and faces have to be perfectly aligned and not overlapping >>> from fipy import * >>> mesh1 = Grid2D(nx=6, ny=2) + (-3.0, 6.0) >>> mesh2 = Grid2D(nx=2, ny=6) >>> mesh = mesh1 + mesh2 >>> print mesh.getCellCenters() [[-2.5 6.5] [-1.5 6.5] [-0.5 6.5] [ 0.5 6.5] [ 1.5 6.5] [ 2.5 6.5] [-2.5 7.5] [-1.5 7.5] [-0.5 7.5] [ 0.5 7.5] [ 1.5 7.5] [ 2.5 7.5] [ 0.5 0.5] [ 1.5 0.5] [ 0.5 1.5] [ 1.5 1.5] [ 0.5 2.5] [ 1.5 2.5] [ 0.5 3.5] [ 1.5 3.5] [ 0.5 4.5] [ 1.5 4.5] [ 0.5 5.5] [ 1.5 5.5]] Thanks, Matt Koch Cheers -- Daniel Wheeler
... cylindrical coordinates ...
Hello there, I am brand new new FiPy, in fact just seem to have managed to install it on Windows 2000 and Slackware 10.2 Linux. This seems like enormously powerful software! I have read some documentation and briefly reviewed the mailing list. There is one entry (http://www.mail-archive.com/fipy@nist.gov/msg00116.html) that seems to speak to the subject, but it is a little too advanced for me. I am just wondering how to set up a problem in cylindrical (r,z) rather than rectangular (x,y) coordinates. Is there a command I should call or is there an object I have to initialize in order to switch on cylindrical coordinates? From the above entry, I am almost guessing that one would have to implement their own divergences and such in cylindrical coordinates by adding the radius in proper places of the divergences and such in rectangular coordinates? That can't be right!? Also, other than using GMsh (which is incredibly awesome software, by the way), how I can I create somewhat more complicated domains than the simple lines, squares and circles used in most of the examples. Can I generate such geometry in FiPy, and can I mesh that then? All I have seen thus far is meshing commands for lines, rectangles or circles. How would I create and mesh, say, a Tee shape? Thanks, Matt Koch
