Re: Setting CellVariable values
> On Apr 10, 2019, at 11:12 AM, Dario Panada wrote: > > In my case, as I just have only one dimension, using sourceGrid.value[i] or > sourceGrid[...,i] should be equivalent though? Yes ___ fipy mailing list fipy@nist.gov http://www.ctcms.nist.gov/fipy [ NIST internal ONLY: https://email.nist.gov/mailman/listinfo/fipy ]
Re: Setting CellVariable values
Thanks, makes sense. In my case, as I just have only one dimension, using sourceGrid.value[i] or sourceGrid[...,i] should be equivalent though? On Tue, Apr 9, 2019 at 3:32 PM Guyer, Jonathan E. Dr. (Fed) via fipy < fipy@nist.gov> wrote: > > On Apr 8, 2019, at 6:38 PM, Dario Panada wrote: > > > DP: I guess what confuses me here is the [..., i] syntax on the > CellVariable object thought. > > FiPy is built on NumPy. `...` or Ellipsis means "all the indices except > for the one specified". FiPy stores cells in the last index of the internal > NumPy array. A CellVariable can potentially be a field of vectors or > tensors, so there could be more leading dimensions. Writing `[..., i]` > ensures you're inserting data where you want. > > > https://docs.scipy.org/doc/numpy/reference/arrays.indexing.html?highlight=ellipsis%20expand > > > > Between this approach and .value, which one would you recommend? > > >>> i = np.ravel_multi_index([coordinate[0], coordinate[1], > coordinate[2]], (20, 20, 20)) > >>> sourceGrid[..., i] = sourceRate > > > ___ > fipy mailing list > fipy@nist.gov > http://www.ctcms.nist.gov/fipy > [ NIST internal ONLY: https://email.nist.gov/mailman/listinfo/fipy ] > ___ fipy mailing list fipy@nist.gov http://www.ctcms.nist.gov/fipy [ NIST internal ONLY: https://email.nist.gov/mailman/listinfo/fipy ]
Re: Setting CellVariable values
> On Apr 8, 2019, at 6:38 PM, Dario Panada wrote: > DP: I guess what confuses me here is the [..., i] syntax on the CellVariable > object thought. FiPy is built on NumPy. `...` or Ellipsis means "all the indices except for the one specified". FiPy stores cells in the last index of the internal NumPy array. A CellVariable can potentially be a field of vectors or tensors, so there could be more leading dimensions. Writing `[..., i]` ensures you're inserting data where you want. https://docs.scipy.org/doc/numpy/reference/arrays.indexing.html?highlight=ellipsis%20expand > Between this approach and .value, which one would you recommend? >>> i = np.ravel_multi_index([coordinate[0], coordinate[1], coordinate[2]], >>> (20, 20, 20)) >>> sourceGrid[..., i] = sourceRate ___ fipy mailing list fipy@nist.gov http://www.ctcms.nist.gov/fipy [ NIST internal ONLY: https://email.nist.gov/mailman/listinfo/fipy ]
Re: Setting CellVariable values
On Mon, Apr 8, 2019 at 11:22 PM Guyer, Jonathan E. Dr. (Fed) via fipy < fipy@nist.gov> wrote: > > > > On Apr 8, 2019, at 4:09 PM, Dario Panada 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 > fipy@nist.gov > http://www.ctcms.nist.gov/fipy > [ NIST internal ONLY: https://email.nist.gov/mailman/listinfo/fipy ] > ___ fipy mailing list fipy@nist.gov http://www.ctcms.nist.gov/fipy [ NIST internal ONLY: https://email.nist.gov/mailman/listinfo/fipy ]
Re: Setting CellVariable values
> On Apr 8, 2019, at 4:09 PM, Dario Panada 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: 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`. > 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 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 fipy@nist.gov http://www.ctcms.nist.gov/fipy [ NIST internal ONLY: https://email.nist.gov/mailman/listinfo/fipy ]
Re: Setting CellVariable values
Martin - That's interesting that `u.value.reshape(Nz,Ny,Nx)` gives you a view on the CellVariable's value. I'd say it's not 100% reliable that it always will, but it probably will. The result is certainly easier to read than juggling around with `ravel_multi_index`. - Jon > On Apr 8, 2019, at 12:01 PM, Martinus WERTS > wrote: > > Dear Dario, > > I am currently using Fipy for a slightly different diffusion-reaction > problem. > > I use a CellVariable on the same grid for the (spatially-dependent) rate > constant. One can set its values in a "numpy-vectorized" fashion by accessing > the "value" property of the CellVariable. > > By using a Boolean expression for indexing the "value" vector one can address > individual elements. > > Here are bits of code that illustrate the approach. It sets the "capture > rate" to Kcap inside a sphere of radius R. Outside the sphere, "capture rate" > is zero. > > # create grid (one octant, using symmetry) > mesh = UniformGrid3D(nx=Nx, ny=Ny, nz=Nz, > dx=sx/Nx, dy=sy/Ny, dz=sz/Nz, > origin=[[0.],[0.],[0.]] ) > X,Y,Z = mesh.cellCenters > > # variables > u = CellVariable(name="particles", >mesh=mesh, >value=0.) > k = CellVariable(name="capture rate", > mesh=mesh, > value=0.) > > # equation > eq = TransientTerm(var = u) == DiffusionTerm(coeff = Dcoeff, var = u) - > k*u > > # I skip the boundary conditions here to keep this message compact > > # initial conditions for u; setting value for rate constant > u.value=Ceq > k.value[(X**2 + Y**2 + Z**2< Rcap**2)] = Kcap > > > I also found that it is possible to access the elements on this regular 3D > grid via a "reshaped" version of the array > > uvol = u.value.reshape(Nz,Ny,Nx) > > (...) > > uvol[:,0,:] += np.sum(vvol, axis=1) > > This approach, however, requires that one does the book-keeping of the > coordinate system oneself, and relies on the specific way that the data is > organized by FiPy. > > Best wishes, > Martin > > > > > > On 08/04/2019 17:30, Dario Panada wrote: >> Hello, >> >> Many thanks for your reply. >> >> Yes, let me provide a bit more context. >> >> I two initial numpy grids (n*n*n) where each value corresponds to a >> source/sink. Eg: Given my source grid and coordinates (1,2,3) having value >> 5, I want to set such value as a source in FiPy. Currently I am dong that >> by, for each such coordinate, finding the corresponding ravelled >> index and setting it in _array, as snippet in my previous message; >> >> i = np.ravel_multi_index([coordinate[0], coordinate[1], coordinate[2]], >> (20, 20, 20)) >> >> sourceGrid._array[i] = sourceRate >> sinkGrid._array[i] = sinkRate >> >> I suppose I could build the entire vector of sources before and then doing a >> single assignment to _array, but again you correctly mentioned >> that relying on that is bad practice. >> >> You mention: >> >> sourceGrid[..., i] = sourceRate >> >> Can I just please confirm what data type sourceGrid is? In the context of >> defining the equation >> >> eq = TransientTerm() == DiffusionTerm(coeff=D) + sourceGrid - sinkGrid >> >> Can sourceGrid/sinkGrid just be numpy arrays or even simple python lists? I >> was under the impression they had to be CellVariable objects but could be >> wrong. >> >> Kind Regards, >> Dario >> >> >> >> On Mon, Apr 8, 2019 at 3:04 PM Guyer, Jonathan E. Dr. (Fed) via fipy >> wrote: >> Iterating over a mesh with a Python `for` loop is, as you've found, an >> incredibly inefficient way to do things. FiPy, like numpy it relies on, is >> intended to be used with vectorized operations. >> >> As far as your approach, things that start with `_` in Python are internal >> implementation details and you should not depend on them. If you find cases >> in FiPy that absolutely require that you access `some._propertyName` or >> `some._methodName()`, then please file an issue explaining your need so that >> we can provide a public interface. >> >> In this case, there's no need to access `_array`. Just write >> >> >>> sourceGrid[..., i] = sourceRate >> >>> sinkGrid[..., i] = sinkRate >> >> HOWEVER, you are still relying on an internal implementation detail, >> specifically that a Grid is an array with known fastest and slowest varying >> axes. We have in FiPy's history switched from Fortran to C ordering, and we >> might conceivably switch back at some point. Further, if you every wanted to >> run your script on an unstructured mesh, then your system wouldn't work at >> all. >> >> `sourceCoords` presumably comes from some definition in terms of geometry >> rather than discrete mesh indices. FiPy is intended to work best with those >> geometric descriptions. If you described where `sourceCoords` came from, we >> could
Re: Setting CellVariable values
> On Apr 8, 2019, at 11:30 AM, Dario Panada wrote: > I two initial numpy grids (n*n*n) where each value corresponds to a > source/sink. Eg: Given my source grid and coordinates (1,2,3) having value 5, > I want to set such value as a source in FiPy. That wasn't my question. When you publish your research, is your paper going to say "We put a source at array index (1,2,3)"? Why did you put it there? What physical process would you be modeling by having a source at index (1,2,3)? Would that physical process be changed by modeling a 40x40x40 grid? > I suppose I could build the entire vector of sources before and then doing a > single assignment to _array, but again you correctly mentioned that relying > on that is bad practice. If you assign to _array, I will change the FiPy codebase for the sole, spiteful purpose of breaking your code. > You mention: > > sourceGrid[..., i] = sourceRate > > Can I just please confirm what data type sourceGrid is? In the context of > defining the equation sourceGrid is a CellVariable > > eq = TransientTerm() == DiffusionTerm(coeff=D) + sourceGrid - sinkGrid > > Can sourceGrid/sinkGrid just be numpy arrays or even simple python lists? I > was under the impression they had to be CellVariable objects but could be > wrong. sourceGrid and sinkGrid must be CellVariables. ___ fipy mailing list fipy@nist.gov http://www.ctcms.nist.gov/fipy [ NIST internal ONLY: https://email.nist.gov/mailman/listinfo/fipy ]
Re: Setting CellVariable values
Dear Martin, Many thanks for your message. I think your approach is not too dissimilar from mine, but you are accessing *.value* of CellVariable whereas I am accessing *._array*. I have no problem switching to that, I'd just like confirmation that we can directly set the values by modifying the properties and that we are not omitting any other configuration that would be handled by using the otherwise provided setter methods. Kind Regards, Dario On Mon, Apr 8, 2019 at 5:04 PM Martinus WERTS wrote: > Dear Dario, > > I am currently using Fipy for a slightly different diffusion-reaction > problem. > > I use a CellVariable on the same grid for the (spatially-dependent) rate > constant. One can set its values in a "numpy-vectorized" fashion by > accessing the "value" property of the CellVariable. > > By using a Boolean expression for indexing the "value" vector one can > address individual elements. > > Here are bits of code that illustrate the approach. It sets the "capture > rate" to Kcap inside a sphere of radius R. Outside the sphere, "capture > rate" is zero. > > # create grid (one octant, using symmetry) > mesh = UniformGrid3D(nx=Nx, ny=Ny, nz=Nz, > dx=sx/Nx, dy=sy/Ny, dz=sz/Nz, > origin=[[0.],[0.],[0.]] ) > X,Y,Z = mesh.cellCenters > > # variables > u = CellVariable(name="particles", >mesh=mesh, >value=0.) > k = CellVariable(name="capture rate", > mesh=mesh, > value=0.) > > # equation > eq = TransientTerm(var = u) == DiffusionTerm(coeff = Dcoeff, var = u) > - k*u > > # I skip the boundary conditions here to keep this message compact > > # initial conditions for u; setting value for rate constant > u.value=Ceq > k.value[(X**2 + Y**2 + Z**2< Rcap**2)] = Kcap > > > I also found that it is possible to access the elements on this regular 3D > grid via a "reshaped" version of the array > > uvol = u.value.reshape(Nz,Ny,Nx) > > (...) > > uvol[:,0,:] += np.sum(vvol, axis=1) > > This approach, however, requires that one does the book-keeping of the > coordinate system oneself, and relies on the specific way that the data is > organized by FiPy. > > Best wishes, > Martin > > > > > > On 08/04/2019 17:30, Dario Panada wrote: > > Hello, > > Many thanks for your reply. > > Yes, let me provide a bit more context. > > I two initial numpy grids (n*n*n) where each value corresponds to a > source/sink. Eg: Given my source grid and coordinates (1,2,3) having value > 5, I want to set such value as a source in FiPy. Currently I am dong that > by, for each such coordinate, finding the corresponding ravelled index and > setting it in _array, as snippet in my previous message; > > *i = np.ravel_multi_index([coordinate[0], coordinate[1], coordinate[2]], > (20, 20, 20))* > > *sourceGrid._array[i] = sourceRate* > *sinkGrid._array[i] = sinkRate* > > I suppose I could build the entire vector of sources before and then doing > a single assignment to _array, but again you correctly mentioned that > relying on that is bad practice. > > You mention: > > *sourceGrid[..., i] = sourceRate* > > Can I just please confirm what data type sourceGrid is? In the context of > defining the equation > > *eq = TransientTerm() == DiffusionTerm(coeff=D) + sourceGrid - sinkGrid* > > Can sourceGrid/sinkGrid just be numpy arrays or even simple python lists? > I was under the impression they had to be CellVariable objects but could be > wrong. > > Kind Regards, > Dario > > > > On Mon, Apr 8, 2019 at 3:04 PM Guyer, Jonathan E. Dr. (Fed) via fipy < > fipy@nist.gov> wrote: > >> Iterating over a mesh with a Python `for` loop is, as you've found, an >> incredibly inefficient way to do things. FiPy, like numpy it relies on, is >> intended to be used with vectorized operations. >> >> As far as your approach, things that start with `_` in Python are >> internal implementation details and you should not depend on them. If you >> find cases in FiPy that absolutely require that you access >> `some._propertyName` or `some._methodName()`, then please file an issue >> explaining your need so that we can provide a public interface. >> >> In this case, there's no need to access `_array`. Just write >> >> >>> sourceGrid[..., i] = sourceRate >> >>> sinkGrid[..., i] = sinkRate >> >> HOWEVER, you are still relying on an internal implementation detail, >> specifically that a Grid is an array with known fastest and slowest varying >> axes. We have in FiPy's history switched from Fortran to C ordering, and we >> might conceivably switch back at some point. Further, if you every wanted >> to run your script on an unstructured mesh, then your system wouldn't work >> at all. >> >> `sourceCoords` presumably comes from some definition in terms of geometry >> rather than discrete mesh indices. FiPy is intended to work best with those >> geometric descriptions. If
Re: Setting CellVariable values
Dear Dario, I am currently using Fipy for a slightly different diffusion-reaction problem. I use a CellVariable on the same grid for the (spatially-dependent) rate constant. One can set its values in a "numpy-vectorized" fashion by accessing the "value" property of the CellVariable. By using a Boolean expression for indexing the "value" vector one can address individual elements. Here are bits of code that illustrate the approach. It sets the "capture rate" to Kcap inside a sphere of radius R. Outside the sphere, "capture rate" is zero. # create grid (one octant, using symmetry) mesh = UniformGrid3D(nx=Nx, ny=Ny, nz=Nz, dx=sx/Nx, dy=sy/Ny, dz=sz/Nz, origin=[[0.],[0.],[0.]] ) X,Y,Z = mesh.cellCenters # variables u = CellVariable(name="particles", mesh=mesh, value=0.) k = CellVariable(name="capture rate", mesh=mesh, value=0.) # equation eq = TransientTerm(var = u) == DiffusionTerm(coeff = Dcoeff, var = u) - k*u # I skip the boundary conditions here to keep this message compact # initial conditions for u; setting value for rate constant u.value=Ceq k.value[(X**2 + Y**2 + Z**2< Rcap**2)] = Kcap I also found that it is possible to access the elements on this regular 3D grid via a "reshaped" version of the array uvol = u.value.reshape(Nz,Ny,Nx) (...) uvol[:,0,:] += np.sum(vvol, axis=1) This approach, however, requires that one does the book-keeping of the coordinate system oneself, and relies on the specific way that the data is organized by FiPy. Best wishes, Martin On 08/04/2019 17:30, Dario Panada wrote: Hello, Many thanks for your reply. Yes, let me provide a bit more context. I two initial numpy grids (n*n*n) where each value corresponds to a source/sink. Eg: Given my source grid and coordinates (1,2,3) having value 5, I want to set such value as a source in FiPy. Currently I am dong that by, for each such coordinate, finding the corresponding ravelled index and setting it in _array, as snippet in my previous message; /i = np.ravel_multi_index([coordinate[0], coordinate[1], coordinate[2]], (20, 20, 20))/ / / / sourceGrid._array[i] = sourceRate/ / sinkGrid._array[i] = sinkRate/ / / I suppose I could build the entire vector of sources before and then doing a single assignment to _array, but again you correctly mentioned that relying on that is bad practice. You mention: /sourceGrid[..., i] = sourceRate/ / / Can I just please confirm what data type sourceGrid is? In the context of defining the equation /eq = TransientTerm() == DiffusionTerm(coeff=D) + sourceGrid - sinkGrid/ / / Can sourceGrid/sinkGrid just be numpy arrays or even simple python lists? I was under the impression they had to be CellVariable objects but could be wrong. Kind Regards, Dario On Mon, Apr 8, 2019 at 3:04 PM Guyer, Jonathan E. Dr. (Fed) via fipy mailto:fipy@nist.gov>> wrote: Iterating over a mesh with a Python `for` loop is, as you've found, an incredibly inefficient way to do things. FiPy, like numpy it relies on, is intended to be used with vectorized operations. As far as your approach, things that start with `_` in Python are internal implementation details and you should not depend on them. If you find cases in FiPy that absolutely require that you access `some._propertyName` or `some._methodName()`, then please file an issue explaining your need so that we can provide a public interface. In this case, there's no need to access `_array`. Just write >>> sourceGrid[..., i] = sourceRate >>> sinkGrid[..., i] = sinkRate HOWEVER, you are still relying on an internal implementation detail, specifically that a Grid is an array with known fastest and slowest varying axes. We have in FiPy's history switched from Fortran to C ordering, and we might conceivably switch back at some point. Further, if you every wanted to run your script on an unstructured mesh, then your system wouldn't work at all. `sourceCoords` presumably comes from some definition in terms of geometry rather than discrete mesh indices. FiPy is intended to work best with those geometric descriptions. If you described where `sourceCoords` came from, we could help with a more FiPyish way to get what you want. > On Apr 6, 2019, at 9:02 AM, Dario Panada mailto:dario.pan...@gmail.com>> wrote: > > Good Afternoon (Morning) to all, > > I have an equation of type > > eq = TransientTerm() == DiffusionTerm(coeff=D) + sourceGrid - sinkGrid > > Where sourceGrid and sinkGrid are derived from values in a 3D grid. > > Is there any downside to declaring the grids as > > sourceGrid = CellVariable(name="source", mesh=Grid3D(dx=1, dy=1, dz=1, nx=20, ny=20,
Re: Setting CellVariable values
Hello, Many thanks for your reply. Yes, let me provide a bit more context. I two initial numpy grids (n*n*n) where each value corresponds to a source/sink. Eg: Given my source grid and coordinates (1,2,3) having value 5, I want to set such value as a source in FiPy. Currently I am dong that by, for each such coordinate, finding the corresponding ravelled index and setting it in _array, as snippet in my previous message; *i = np.ravel_multi_index([coordinate[0], coordinate[1], coordinate[2]], (20, 20, 20))* *sourceGrid._array[i] = sourceRate* *sinkGrid._array[i] = sinkRate* I suppose I could build the entire vector of sources before and then doing a single assignment to _array, but again you correctly mentioned that relying on that is bad practice. You mention: *sourceGrid[..., i] = sourceRate* Can I just please confirm what data type sourceGrid is? In the context of defining the equation *eq = TransientTerm() == DiffusionTerm(coeff=D) + sourceGrid - sinkGrid* Can sourceGrid/sinkGrid just be numpy arrays or even simple python lists? I was under the impression they had to be CellVariable objects but could be wrong. Kind Regards, Dario On Mon, Apr 8, 2019 at 3:04 PM Guyer, Jonathan E. Dr. (Fed) via fipy < fipy@nist.gov> wrote: > Iterating over a mesh with a Python `for` loop is, as you've found, an > incredibly inefficient way to do things. FiPy, like numpy it relies on, is > intended to be used with vectorized operations. > > As far as your approach, things that start with `_` in Python are internal > implementation details and you should not depend on them. If you find cases > in FiPy that absolutely require that you access `some._propertyName` or > `some._methodName()`, then please file an issue explaining your need so > that we can provide a public interface. > > In this case, there's no need to access `_array`. Just write > > >>> sourceGrid[..., i] = sourceRate > >>> sinkGrid[..., i] = sinkRate > > HOWEVER, you are still relying on an internal implementation detail, > specifically that a Grid is an array with known fastest and slowest varying > axes. We have in FiPy's history switched from Fortran to C ordering, and we > might conceivably switch back at some point. Further, if you every wanted > to run your script on an unstructured mesh, then your system wouldn't work > at all. > > `sourceCoords` presumably comes from some definition in terms of geometry > rather than discrete mesh indices. FiPy is intended to work best with those > geometric descriptions. If you described where `sourceCoords` came from, we > could help with a more FiPyish way to get what you want. > > > > > On Apr 6, 2019, at 9:02 AM, Dario Panada wrote: > > > > Good Afternoon (Morning) to all, > > > > I have an equation of type > > > > eq = TransientTerm() == DiffusionTerm(coeff=D) + sourceGrid - sinkGrid > > > > Where sourceGrid and sinkGrid are derived from values in a 3D grid. > > > > Is there any downside to declaring the grids as > > > > sourceGrid = CellVariable(name="source", mesh=Grid3D(dx=1, dy=1, dz=1, > nx=20, ny=20, nz=20)) > > sinkGrid = CellVariable(name="sink", mesh=Grid3D(dx=1, dy=1, > dz=1, nx=20, ny=20, nz=20)) > > > > And populating them as: > > > > i = np.ravel_multi_index([coordinate[0], coordinate[1], coordinate[2]], > (20, 20, 20)) > > > > sourceGrid._array[i] = sourceRate > > sinkGrid._array[i] = sinkRate > > > > The original procedure I was using (given below) where I called > .setValue on each coordinate is extremely time-consuming. Results seem to > align, but of course this doesn't mean it's right... Or if it's wrong, any > specific advice on how to achieve this? > > > > Thanks, > > Dario > > > > Original approach (and there is an equivalent function for > setupSinkGrid): > > def setupSourceGrid_(self, sourceCoords, mesh): > > sourceGrid = CellVariable(name="source", mesh=mesh, value=0) > > sourceGrid.setValue(0.) > > for pos, v in sourceCoords.iteritems(): > > tmpGrid = [False for _ in range(8000)] > > i = np.ravel_multi_index([pos[0], pos[1], pos[2]], (20, 20, > 20)) > > tmpGrid[i] = True > > sourceGrid.setValue(v, where=tmpGrid) > > > > ___ > > fipy mailing list > > fipy@nist.gov > > http://www.ctcms.nist.gov/fipy > > [ NIST internal ONLY: https://email.nist.gov/mailman/listinfo/fipy ] > > > ___ > fipy mailing list > fipy@nist.gov > http://www.ctcms.nist.gov/fipy > [ NIST internal ONLY: https://email.nist.gov/mailman/listinfo/fipy ] > ___ fipy mailing list fipy@nist.gov http://www.ctcms.nist.gov/fipy [ NIST internal ONLY: https://email.nist.gov/mailman/listinfo/fipy ]
Re: Setting CellVariable values
Iterating over a mesh with a Python `for` loop is, as you've found, an incredibly inefficient way to do things. FiPy, like numpy it relies on, is intended to be used with vectorized operations. As far as your approach, things that start with `_` in Python are internal implementation details and you should not depend on them. If you find cases in FiPy that absolutely require that you access `some._propertyName` or `some._methodName()`, then please file an issue explaining your need so that we can provide a public interface. In this case, there's no need to access `_array`. Just write >>> sourceGrid[..., i] = sourceRate >>> sinkGrid[..., i] = sinkRate HOWEVER, you are still relying on an internal implementation detail, specifically that a Grid is an array with known fastest and slowest varying axes. We have in FiPy's history switched from Fortran to C ordering, and we might conceivably switch back at some point. Further, if you every wanted to run your script on an unstructured mesh, then your system wouldn't work at all. `sourceCoords` presumably comes from some definition in terms of geometry rather than discrete mesh indices. FiPy is intended to work best with those geometric descriptions. If you described where `sourceCoords` came from, we could help with a more FiPyish way to get what you want. > On Apr 6, 2019, at 9:02 AM, Dario Panada wrote: > > Good Afternoon (Morning) to all, > > I have an equation of type > > eq = TransientTerm() == DiffusionTerm(coeff=D) + sourceGrid - sinkGrid > > Where sourceGrid and sinkGrid are derived from values in a 3D grid. > > Is there any downside to declaring the grids as > > sourceGrid = CellVariable(name="source", mesh=Grid3D(dx=1, dy=1, dz=1, nx=20, > ny=20, nz=20)) > sinkGrid = CellVariable(name="sink", mesh=Grid3D(dx=1, dy=1, dz=1, > nx=20, ny=20, nz=20)) > > And populating them as: > > i = np.ravel_multi_index([coordinate[0], coordinate[1], coordinate[2]], (20, > 20, 20)) > > sourceGrid._array[i] = sourceRate > sinkGrid._array[i] = sinkRate > > The original procedure I was using (given below) where I called .setValue on > each coordinate is extremely time-consuming. Results seem to align, but of > course this doesn't mean it's right... Or if it's wrong, any specific advice > on how to achieve this? > > Thanks, > Dario > > Original approach (and there is an equivalent function for setupSinkGrid): > def setupSourceGrid_(self, sourceCoords, mesh): > sourceGrid = CellVariable(name="source", mesh=mesh, value=0) > sourceGrid.setValue(0.) > for pos, v in sourceCoords.iteritems(): > tmpGrid = [False for _ in range(8000)] > i = np.ravel_multi_index([pos[0], pos[1], pos[2]], (20, 20, 20)) > tmpGrid[i] = True > sourceGrid.setValue(v, where=tmpGrid) > > ___ > fipy mailing list > fipy@nist.gov > http://www.ctcms.nist.gov/fipy > [ NIST internal ONLY: https://email.nist.gov/mailman/listinfo/fipy ] ___ fipy mailing list fipy@nist.gov http://www.ctcms.nist.gov/fipy [ NIST internal ONLY: https://email.nist.gov/mailman/listinfo/fipy ]
