how to set up data transfer between two adjacent nonuniform meshs
Hello All, I wonder is there any way to allow the data share on the two nonuniform mesh's interface ? To explain this, let's say I have two meshes, mesh_1 and mesh_2. Different equations govern the mesh_1 and mesh_2, and solution variable on both meshes is phi. I would like the outlet (on the right face) on mesh_1 served as inlet(on the left face) on mesh_2. I tired to concatenate two mesh. If they are uniform, this works fine. However, if two does not share the exact the same face (for example, one is uniform, and another is nonuniform), there seems to be problem. . Thus, I wonder is there any way to "interpolate" the phi.facevalue on mesh_1 outlet face, and apply this interpolation value into the inlet of mesh_2? Best, Zhekai ___ fipy mailing list fipy@nist.gov http://www.ctcms.nist.gov/fipy [ NIST internal ONLY: https://email.nist.gov/mailman/listinfo/fipy ]
Re: Interesting (perhaps unique) approach to parallelising FiPy sweeps
On Fri, Sep 16, 2016 at 3:38 PM, Gopalakrishnan, Krishnakumar wrote: > > The questions are : 1) Has anybody tried this before ? 2) Does this sound > problematic from a technical or practical perspective. 3) Does this sound > remotely useful. To my knowledge, this hasn't been done with FiPy. Certainly, this can be set up with FiPy using mpi4py or ipython's parallel tools, which you seem to have done below. It could well be useful in specific cases, but In general this approach is very limited since you can't scale to different number of processors so I would definitely not recommend making too much effort. > I have successfully implemented a multiprocessor parallelisation for > examples.diffusion.coupled (shown below) . The values of the simulation > results (for v0 & v1) after 100 time-steps are very very close to that of the > serial sweep. Although this code is several times slower than the serial > code, we tried this more as a concept demonstrator before embarking to spend > significant effort to convert our serial code to multiprocessor approach. If > you see a red flag, it would be much appreciated if you can help us by > pointing it out. I don't see a red flag there. Try to set it up so that the equations are not redefined for every sweep. Also, do an in place update of the variables using [:] or setValue (return the array rather than the variable from get_res). -- Daniel Wheeler ___ fipy mailing list fipy@nist.gov http://www.ctcms.nist.gov/fipy [ NIST internal ONLY: https://email.nist.gov/mailman/listinfo/fipy ]
