On Wed, Jan 4, 2012 at 8:51 AM, Daniel Wheeler <[email protected]> wrote: > > > 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.
Sorry, what I mean by a "constructed operation" are the "lazy" operations which don't actually do the computation until one does a getNumericValue(). I guess what I was asking was whether that would imply a gather or not, sounds like it does. When I did some quick tests it did seem like I got the same results from each thread if I let them all do these operations rather than let just node 0 do it. Kudos for keeping it fairly simple from the top level. > >> >> 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. Got it. > > Cheers > > -- > Daniel Wheeler > > _______________________________________________ > fipy mailing list > [email protected] > http://www.ctcms.nist.gov/fipy > [ NIST internal ONLY: https://email.nist.gov/mailman/listinfo/fipy ] > _______________________________________________ fipy mailing list [email protected] http://www.ctcms.nist.gov/fipy [ NIST internal ONLY: https://email.nist.gov/mailman/listinfo/fipy ]
