On Mon, Apr 8, 2019 at 11:22 PM Guyer, Jonathan E. Dr. (Fed) via fipy < [email protected]> wrote:
> > > > On Apr 8, 2019, at 4:09 PM, Dario Panada <[email protected]> wrote: > > > > DP: That would be diffusion of solubles from blood vessels (endothelial > cells). Specifically, glucose or oxygen. It wouldn't change significantly > be increasing it to a 40x40x40 grid, you'd just be simulating a larger > section of tissue. > > Blood vessels aren't 20x20x20 grids and don't have locations like (1,2,3) > in them. What I'm trying (and failing) to get at is that you have some > physical locations, in micrometers or furlongs or lightyears, that you > actually care about. It is better in FiPy to think about the things that > you *really* care about and not try to second guess what FiPy cares about. > Grid locations are an implementation detail. If you do grid convergence > studies (and you should), then your grid locations will all change, but the > physical definitions of them won't. > DP: Aha, ok, that makes more sense. So each grid position/coordinate corresponds to 0.042mm3, and can contain none, one or many endothelial cells. The sum of endothelial cells multiplied by the oxygen emission rate of individual cells produces the source value at that position. I hope that makes more sense? > > > DP: English is my first language but I think that's some tough sarcasm > to tell me not to do that. In that case, I'll happily take advice on proper > ways of achieving the same result so as not to cumber the dev team with > unnecessary refactoring. > > I concede the sarcasm. I explained the proper way of achieving the same > result in my first reply and the discussion kept going on about `_array`. > Don't use `var._array`. Use `var` or `var.value`. > DP: I've refactored to use value. > > > So, in essence, I have a 20x20x20 grid of values. I want to somehow > input these values into a 20x20x20 structured mesh in the CellVariable > object. The fact that the approach might not work in unstructured meshes > isn't concerning because I don't require that feature. Setting values in > _array appears to work but is not an acceptable solution. From the previous > exchange with Martin, using the value property appears possible, although > raveling indexes has also been discouraged. So, any advice? > > As I said in my first response: > > >>> i = np.ravel_multi_index([coordinate[0], coordinate[1], > coordinate[2]], (20, 20, 20)) > >>> sourceGrid[..., i] = sourceRate > > DP: I guess what confuses me here is the [..., i] syntax on the CellVariable object thought. Between this approach and .value, which one would you recommend? > Martin's suggestion of > > >>> sourceView = sourceGrid.value.reshape(20, 20, 20) > >>> sourceView[coordinate] = sourceRate > > is interesting. It's a little fragile (if the internal storage was strided > for some reason, then I don't think it would work), but it's worth > considering and I, at least, find it clearer. > > Raveling is not discouraged per se. Martin's `reshape` amounts to the same > thing. > > > _______________________________________________ > 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 ]
