Hi Dean, Thanks for your interest in fipy.
On Wed, Mar 12, 2008 at 8:01 PM, fred2 <[EMAIL PROTECTED]> wrote: > > hello fipy developers & experts, > > thanks much for making fipy available. it looks to be a very useful and > thorough tool. > > i am interested in trying to apply it to some nonlinear equation sets (best > case, something analogous to the compressible navier-stokes equations). I am currently using fipy to model the compressible Navier-Stokes equations in 2D. > i see ticket 45 has some (old?) discussion about n.s. (status: assigned, > version: next release), but couldn't find any details; the mail archive > doesn't look to have any related threads. I haven't added any full Navier-Stokes examples to fipy yet. It is something I must do. It probably will not happen before the next release, but will happen by the release after that. > if this ticket is not currently under continuing development, do you have > any thoughts on the feasibility? (i did definitely see the caveats listed in > the stokes flow example case, but didn't see any examples that showed "you > can't solve this form...", or "you would need to modify this routine..." ). Currently in the problem that I am working on, I have a pressure that depends on density. The technique is akin to the SIMPLE algorithm where the momentum equations are solved initially and then the continuity equation is solved to correct the density (rather than pressure). The density corrections are then used to correct the velocities. Rhie-Chow interpolation is used to avoid velocity-pressure decoupling. Unfortunately, I can't release the code because we haven't published anything yet. > i pulled a recent fipy from your svn server. i've looked a bit at the > vanleer convection term. the source code (inputVanLeerUpwind.py) references > the url: http://www.gre.ac.uk/~physica/phy2.12/theory/node173.htm > > which i believe no longer exists. Thanks. > i think the term is using a minmod > limiter, but i could not match it up with those listed, e.g. at > http://en.wikipedia.org/wiki/Flux_limiter. if you think that the > implementation may need some review, i would be happy to look in detail at > it (but see also below); do you have another reference to the > implementation? Hmm. Not off hand. The implementation is rather experimental, we never actually used it for anything useful. > for the square wave advection test case, the example code mentions: > "Currently after 20 steps the wave has lost 23% of its height. Van Leer > should do better than this." > > i've done some parametrics for advection for both the square wave & a sin > wave. for both cases, the term conserves speed in the domain, while showing > reasonable conservation of energy (speed**2). the (rate of) energy loss can > be minimized for a suitably large number of grid points (several times > greater than used in the example case). (though, as expected the square wave > requires many more than the sin wave for the same error). the sin wave also > shows there are no noticeable dispersion errors. i'd be happy to send you > these cases, if they would be useful to you in testing or for documentation. Thanks very much for looking into this. Yes, please do send your examples and I'll try to add them in if I get a chance. Currently, we are not particularly motivated towards looking at flux limiting schemes as they don't have much relevance to our problems. For interface dynamics, we use the phase field and level set methods, which don't require these schemes. Flux limiting schemes are generally useful for tracking shocks, while the phase field and level set methods are used for diffuse interfaces. > i have done some quick testing on various forms of the burger equation. i > find good results as expected for the linear forms, but i am having some > difficulty figuring out the best way to handle the nonlinear form (or even > figuring out if such an equation is suitable for fipy). What do you mean by the linear forms? Do you mean the linear terms? Anyhow to solve Burger's equation in 1D you would write your equation like this. >>> u = CellVariable(mesh=mesh) >>> eqn = (TransientTerm() + ConvectionTerm(u / 2) == DiffusoinTerm(nu)) Both u's have been take inside the operator in the convection term. The important thing to note is that FiPy needs to have all coefficients inside the operator. This can nearly always be achieved by manipulation of the equation. You can now solve this equation by stepping and sweeping at each step >>> for step in range(steps): ... for sweep in range(sweeps): ... eqn.solve(u, dt=dt, boundaryConditions=...) This has now become a non-linear solver using fixed point iteration at each time step (Picard iteration). You may be able to get better convergence by taking the variational derivative and solving the corrected equation. However, for nearly everything I just use fixed point iteration. > the general things i may ultimately be trying to do are probably analogous > to the caveats listed in the stokes flow writeup, so i'd be happy to > contribute anything i learn in my testing to the effort. > > i looked a bit at trilinos - it looks to be a good tool, but i assume the > learning curve is rather large. Are you aware that we have a flag to use the trilinos solvers as a solver option rather than pysparse? I use the trilinos multilevel preconditioners for the compressible flow problems in fipy. More efficient and less memory than pysparse. > my other option would probably be to code up > a simple explicit vintage maccormack scheme (don't know whether that would > be something that could be abstracted enough to be useful to fipy). Sure. I think you could do that in fipy by creating two equations. Not sure about the details, but I think it's possible. Please do send back the Van Leer test cases back and I'll update the docs with them. Cheers -- Daniel Wheeler
