On Fri, Dec 30, 2011 at 9:16 PM, James Snyder <[email protected]>wrote:
> > This is nice to hear. I just blindly tried this so it looks like it's > in the 2.2-dev series? > It is. > On this front, I have a few other questions which relate partly to > serial and partly to parallel-context computations: > If I want to get the current measurements I was computing near the end > of the code that was posted and I want to vary parameters that will > change how the mesh is generated (position of the pod), is there > anything I need to do in particular for parallel computation to ensure > proper synchronization if I just put all of that in a for loop as in > the example? No. I don't think anything needs to be done differently. It should all work as if you were working in serial. > Or should I be using synchronization primitives from > mpi4py? There shouldn't be any need. Likewise for the computation of voltages from the > cellvariable or currents derived from gradients of that cell variable > should I just make sure that I only do that on one node (maybe node > 0?) and it will use cells from the global set? Say if I'm using these > types of terms of terms for current computation: > topflux =(flux*mesh.physicalFaces['EcBack']).dot(projections).sum() > Any gather operations should have no differences between the serial and parallel versions. > then getting: topflux.getNumericValue() > > I see there's a getGlobalValue, but that doesn't apply to something > that's a constructed operation. > Not sure what a constructed operation is. In parallel, the "getValue" operation only returns the local array. Hence the need for "getGlobalValue". This should only really be required when viewing the date for debugging purposes or something like that or if you write your own output method or your own viewer. > I've also encountered some failures in single CPU serial computations > where I try a range of parameters that will generate new meshes each > time, that don't seem to be related to parameter selections (i.e.: > retry the parameter that the failure occurred at and it succeeds), but > a number of these types of computations serially seems to eventually > fail at something related to meshing. I haven't completely tracked > this down, but I'll file a ticket if it seems to be a bug on fipy's > side and not something I'm doing or an issue wth Gmsh. > Great. Thanks. We'll try and repair stuff before the next release. > One last question: > Is it possible to have units apply to the dimensions of the mesh? It > would be nice to have some unit verification applied to some of the > calculations being done, but it seems like this would be dependent on > knowing that the dimensions of the mesh is in, say, meters? > This may work on a branch in which we are trying to make variable objects work with all the meshing routines. However, at the current time we are not using units very much because of the difficulties we had making them work pervasively throughout fipy including terms and equations. I'm sure we'll give it another stab in the future. Maybe when numpy has some support for units. Cheers -- Daniel Wheeler
_______________________________________________ fipy mailing list [email protected] http://www.ctcms.nist.gov/fipy [ NIST internal ONLY: https://email.nist.gov/mailman/listinfo/fipy ]
