On Jun 6, 2012, at 7:57 PM, Yun Tao wrote: > 1. Setting the time interval based on CFL condition resolves the instability > issue. Since my solution has n=2, I'm multiplying another 0.5 to the 0.1 * dx > / maximum_velocity. Given both feedbacks from Daniel and Jonathan, I assume > that for an advection-diffusion problem, the magnitude of the diffusion > coefficient is negligible in the configuration of time steps since CFL > doesn't take that into account. Am I right?
The implicit DiffusionTerm is unconditionally stable. There can be accuracy concerns with too-large timesteps, but you don't need to worry about stability. > 2. I followed the given advise and ran the simulation under fixed boundary > conditions and, as shown in the video attachment (s-cd2d), the bivariate > solution convects without noticeable edge effect. However, I do wonder if > another solution is to keep the fixed flux but implement a conservational > constraint on the probability density function, rendering the integration of > the solutions across the 2D domain equaling unity? If so, how would one go > about inserting this condition into the solver? But if the peak is advecting out of the domain, then it is not conserved. > *Staring at the convecting bivariate distribution some more, I noticed a > bright blue band on the outer periphery of the central solutions. This struck > me as odd since, based on the colorbar scheme, it seems to suggest that my > circular normal distribution has a peak at a far radius before the curve > drops down again.. Matplotlib anomaly perhaps? Any explanation would help. I believe that is an artifact of the Matplotlib color scheme. > 3. I'm glad to report the irregular cropping behavior in MatplotlibViewer and > am looking forward to the bugfix. However, when I tried calling > Matplotlib2DViewer instead using the script in > http://matforge.org/fipy/ticket/444, I get a > > NameError: name 'Matplotlib2DViewer' is not defined What version of FiPy are you running? As far as I can tell, Matplotlib2DViewer has been imported by `from fipy import *` for about six years. > 4. Regarding my effort to generate a fixed point advection, I have consulted > this old exchange on the listserve: > http://comments.gmane.org/gmane.comp.python.fipy/1412. The command given by > Jonathan worked like a charm (see it in action in s-cd1dx.mp4). However, > three years after the post, it appears that simple getCellCenters() and > getFaceCenters() still don't return the proper mesh variables but only arrays > of the same shape. Is the interim solution at the end of that link a > permanent one then due to numerical complication? getFaceCenters() apparently never got updated, but getCellCenters() has returned a CellVariable for about two years. What version of FiPy are you running? I filed ticket:445 on getFaceCenters() and if there aren't any unintended consequences, it should return a FaceVariable in the next release. > Once again, I can't adequately express my sincerest gratitude towards this > group. I learned more about numerical methods and even PDEs here than any > class I've ever taken. We're glad FiPy is working for you. _______________________________________________ fipy mailing list [email protected] http://www.ctcms.nist.gov/fipy [ NIST internal ONLY: https://email.nist.gov/mailman/listinfo/fipy ]
