June 2012 - petsc-dev - mailman3.cels.anl.gov

Re: [petsc-dev] Use of PETSc in real-time applications
by Shrirang Abhyankar 06 Jun '12

06 Jun '12

Thanks Jed. On Jun 6, 2012, at 5:33 PM, Jed Brown wrote: > @article{akcelik2005ddd, > title={{Dynamic data-driven inversion for terascale simulations: real-time identification of airborne contaminants}}, > author={Ak\c{c}elik, V. and Biros, G. and Draganescu, A. and Hill, J. and Ghattas, O. and van Bloemen Waanders, B.}, > journal={Proceedings of the 2005 ACM/IEEE conference on Supercomputing}, > year={2005}, > publisher={IEEE Computer Society Washington, DC, USA} > } > > On Wed, Jun 6, 2012 at 5:21 PM, Shri <abhyshr(a)mcs.anl.gov> wrote: > Hi, > I'm trying to compile a list of real-time applications using PETSc. Three applications are listed on the PETSc applications page. > > Computational Infrastructure for the Real-Time Patient-Specific Treatment of Cancer, K. R. Diller, J. T. Oden, C. Bajaj, J. C. Browne, J. Hazle, I. Babu{\vs}ka, J. Bass, L. Bidaut, L. Demkowicz, A. Elliott, Y. Feng, D. Fuentes, S. Goswami, A. Hawkins, S. Khoshnevis, B. Kwon, S. Prudhomme, and R. J. Stafford, University of Texas at Austin, 2008 (link broken) > > Real-Time Registration of Volumetic Brain MRI by Biomechanical Simulation of Deformation during Image Guided Neurosurgery, Simon K. Warfield, Florin Talos, Alida Tei, Arya Nabavi, Matthieu Ferrant, Peter McL. Black, Ferenc A. Jolesz, and Ron Kikinis, Computing and Visualization in Science, 2002. (link broken) > > Real-Time Biomechanical Simulation of Volumetric Brain Deformation for Image Guided Neurosurgery, Simon K. Warfield, Matthieu Ferrant, Xavier Gallez, Arya Nabavi, Ferenc A. Jolesz, and Ron Kikinis, Proceedings of SC2000, 2000. > > Please let me know if there are any more. > > Thanks, > Shri >

1 0

Re: [petsc-dev] Use of PETSc in real-time applications
by Jed Brown 06 Jun '12

06 Jun '12

@article{akcelik2005ddd, title={{Dynamic data-driven inversion for terascale simulations: real-time identification of airborne contaminants}}, author={Ak\c{c}elik, V. and Biros, G. and Draganescu, A. and Hill, J. and Ghattas, O. and van Bloemen Waanders, B.}, journal={Proceedings of the 2005 ACM/IEEE conference on Supercomputing}, year={2005}, publisher={IEEE Computer Society Washington, DC, USA} } On Wed, Jun 6, 2012 at 5:21 PM, Shri <abhyshr(a)mcs.anl.gov> wrote: > Hi, > I'm trying to compile a list of real-time applications using PETSc. Three > applications are listed on the PETSc applications page. > > Computational Infrastructure for the Real-Time Patient-Specific Treatment > of Cancer, K. R. Diller, J. T. Oden, C. Bajaj, J. C. Browne, J. Hazle, I. > Babu{\vs}ka, J. Bass, L. Bidaut, L. Demkowicz, A. Elliott, Y. Feng, D. > Fuentes, S. Goswami, A. Hawkins, S. Khoshnevis, B. Kwon, S. Prudhomme, and > R. J. Stafford, University of Texas at Austin, 2008 (link broken) > > Real-Time Registration of Volumetic Brain MRI by Biomechanical Simulation > of Deformation during Image Guided Neurosurgery, Simon K. Warfield, Florin > Talos, Alida Tei, Arya Nabavi, Matthieu Ferrant, Peter McL. Black, Ferenc > A. Jolesz, and Ron Kikinis, Computing and Visualization in Science, 2002. > (link broken) > > Real-Time Biomechanical Simulation of Volumetric Brain Deformation for > Image Guided Neurosurgery, Simon K. Warfield, Matthieu Ferrant, Xavier > Gallez, Arya Nabavi, Ferenc A. Jolesz, and Ron Kikinis, Proceedings of > SC2000, 2000. > > Please let me know if there are any more. > > Thanks, > Shri >

1 0

Use of PETSc in real-time applications
by Shri 06 Jun '12

06 Jun '12

Hi, I'm trying to compile a list of real-time applications using PETSc. Three applications are listed on the PETSc applications page. Computational Infrastructure for the Real-Time Patient-Specific Treatment of Cancer, K. R. Diller, J. T. Oden, C. Bajaj, J. C. Browne, J. Hazle, I. Babu{\vs}ka, J. Bass, L. Bidaut, L. Demkowicz, A. Elliott, Y. Feng, D. Fuentes, S. Goswami, A. Hawkins, S. Khoshnevis, B. Kwon, S. Prudhomme, and R. J. Stafford, University of Texas at Austin, 2008 (link broken) Real-Time Registration of Volumetic Brain MRI by Biomechanical Simulation of Deformation during Image Guided Neurosurgery, Simon K. Warfield, Florin Talos, Alida Tei, Arya Nabavi, Matthieu Ferrant, Peter McL. Black, Ferenc A. Jolesz, and Ron Kikinis, Computing and Visualization in Science, 2002. (link broken) Real-Time Biomechanical Simulation of Volumetric Brain Deformation for Image Guided Neurosurgery, Simon K. Warfield, Matthieu Ferrant, Xavier Gallez, Arya Nabavi, Ferenc A. Jolesz, and Ron Kikinis, Proceedings of SC2000, 2000. Please let me know if there are any more. Thanks, Shri

1 0

Viewing MPI matrices
by Dmitry Karpeev 06 Jun '12

06 Jun '12

When viewing a MATMPIAIJ on a communicator of size>1, one can see something like this (in an ASCII viewer): Matrix Object: 1 MPI processes type: mpiaij row 0: (0, -8.32667e-17 + 0.4 i) (1, -1) (2, -1) row 1: (0, -1) (1, -8.32667e-17 + 0.4 i) (3, -1) (8, -1) row 2: (0, -1) (2, -8.32667e-17 + 0.4 i) (3, -1) (4, -1) That may be a bit confusing, since the matrix one is trying to view has more than 1 ranks. This is, of course, the result of the way MatView is implemented: pull the distributed matrix into an MPIAIJ that lives on a communicator of size 1 containing the rank 0 of the original comm, then view that auxiliary matrix. Should we try to print the original comm size here, instead of "1 MPI processes"? That can be easily done by composing the original matrix with the auxiliary one and extracting it to check the comm size in MatView_SeqXXX. Alternatively, we could attach just the original comm size to the auxiliary Mat. Or am I the only one bothered by this? Dmitry.

1 0

Re: [petsc-dev] PCFieldSplitSetFields() API change
by Dmitry Karpeev 06 Jun '12

06 Jun '12

On Wed, Jun 6, 2012 at 4:58 PM, Jed Brown <jedbrown(a)mcs.anl.gov> wrote: > On Fri, Mar 23, 2012 at 10:15 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > >> >> On Mar 23, 2012, at 6:22 PM, Jed Brown wrote: >> >> > But what does using B as 00 block actually mean? It seems to me that >> you pivot, producing P' P J where P J has B in the 00 location. >> >> I am not arguing if it is pivoting or not. I'm arguing what the user >> interface should be. Say I want D to be the 00 block then I just set that >> with PCFieldSplitSetFields() as the zeroth field. My point is that I am >> proposing a SINGLE interface for setting the blocks locations in all >> circumstances, while you are proposing having an additional interface for >> certain 00 configurations (pivoting) thus with your model you first call >> the PCFieldSplitSetFields() and then something else. > > > I just talked about this more with Dmitry. > > It seems that we need to name both the row and column spaces of the > operator. > The reason is that we need to be able to address the subproblem (e.g., from the command-line to dial its solver options), not the individual row (output) or col (input) fields. And a subproblem, by definition, involves an input-output (col-row) pair. Further, if we wanted to recursively split/domain-decompose/coarsen the subproblem, we might want to associate a subDM with it. If we associated subDMs with each row and col split, a subproblem would end up with a pair of subDMs, which wouldn't be all that useful. > Which begs the question: what is DM? Is it a distribution of the state > space (column space for a linear operator), a distribution of the residual > space (row space), or both? If both, we should make it possible to select > arbitrary pairs. > A DM, in my view, should a "(sub)problem", which can be solved, hence, implicitly, is square. Further, as currently implemented, a DM uses the same distribution for solutions and residuals (since there is only one DMCreateGlobalVector()). This actually works for PCFieldSplit, because the implied meaning of a field split is a nodewise split of the degrees of freedom over some background mesh, with the distribution of nodes determining the dof distribution. The reason this works for PCASM is that we demand that the input/output spaces are nested (e.g., the output space for RASM is a subspace of the input). I don't know whether we want to generalize away from it. Even within the current DM model it defines a subproblem that can be used in FieldSplit and ASM. All we have to do, if we are to stick with this, is make sure that the local sizes match for the ISs in the pair defining a subproblem. Dmitry.

1 0

Re: [petsc-dev] PCFieldSplitSetFields() API change
by Jed Brown 06 Jun '12

06 Jun '12

On Fri, Mar 23, 2012 at 10:15 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > > On Mar 23, 2012, at 6:22 PM, Jed Brown wrote: > > > But what does using B as 00 block actually mean? It seems to me that you > pivot, producing P' P J where P J has B in the 00 location. > > I am not arguing if it is pivoting or not. I'm arguing what the user > interface should be. Say I want D to be the 00 block then I just set that > with PCFieldSplitSetFields() as the zeroth field. My point is that I am > proposing a SINGLE interface for setting the blocks locations in all > circumstances, while you are proposing having an additional interface for > certain 00 configurations (pivoting) thus with your model you first call > the PCFieldSplitSetFields() and then something else. I just talked about this more with Dmitry. It seems that we need to name both the row and column spaces of the operator. Which begs the question: what is DM? Is it a distribution of the state space (column space for a linear operator), a distribution of the residual space (row space), or both? If both, we should make it possible to select arbitrary pairs.

1 0

Re: [petsc-dev] Fwd: [petsc-maint #119133] petsc-dev configure crash
by Jed Brown 06 Jun '12

06 Jun '12

On Wed, Jun 6, 2012 at 4:35 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > "you commit to petsc-dev " > > Show me the EXACT syntax you use to "commit to petsc-dev" and I'll show > you something stupid that no one will use. > $ hg -R config/BuildSystem pull -u # Get that cool stuff, otherwise how would you know it's there $ hg commit -m'cool stuff in BuildSystem'

1 0

Re: [petsc-dev] Fwd: [petsc-maint #119133] petsc-dev configure crash
by Barry Smith 06 Jun '12

06 Jun '12

On Jun 6, 2012, at 4:24 PM, Jed Brown wrote: > On Wed, Jun 6, 2012 at 3:58 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > What if it is some great fundamental improvement to BuildSystem (like removing 70% of the code and making the rest a million times better)? We in petsc-dev don't benefit from that? That is freaking insane and stupid! Of course we want all updates to BuildSystem otherwise there are essentially two different repositories evolving over time with different things in each one. That is freaking insane! Who designed this stupid subrepo shit? It is completely garbage if what you say is true. > > It's really simple, you commit to petsc-dev after the cool stuff goes into BuildSystem. "you commit to petsc-dev " Show me the EXACT syntax you use to "commit to petsc-dev" and I'll show you something stupid that no one will use. Barry > > It's a small price to pay for being able to go back to a consistent state and not needing to remember to update BuildSystem.

1 0

Re: [petsc-dev] Fwd: [petsc-maint #119133] petsc-dev configure crash
by Jed Brown 06 Jun '12

06 Jun '12

On Wed, Jun 6, 2012 at 3:58 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > What if it is some great fundamental improvement to BuildSystem (like > removing 70% of the code and making the rest a million times better)? We in > petsc-dev don't benefit from that? That is freaking insane and stupid! Of > course we want all updates to BuildSystem otherwise there are essentially > two different repositories evolving over time with different things in each > one. That is freaking insane! Who designed this stupid subrepo shit? It is > completely garbage if what you say is true. It's really simple, you commit to petsc-dev after the cool stuff goes into BuildSystem. It's a small price to pay for being able to go back to a consistent state and not needing to remember to update BuildSystem.

1 0

Re: [petsc-dev] Fwd: [petsc-maint #119133] petsc-dev configure crash
by Barry Smith 06 Jun '12

06 Jun '12

On Jun 6, 2012, at 3:55 PM, Jed Brown wrote: > On Wed, Jun 6, 2012 at 3:51 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > But this is not going to happen. If Matt fixes something in BuildSystem (for some reason not specific to something in petsc-dev he is working on) he will not doing it petsc-dev he will do it in BuildSystem. > > That's fine, if it was unrelated to petsc then it sounds like PETSc didn't need the patch. If it needs the patch then there should be a commit saying so in petsc-dev. What if it is some great fundamental improvement to BuildSystem (like removing 70% of the code and making the rest a million times better)? We in petsc-dev don't benefit from that? That is freaking insane and stupid! Of course we want all updates to BuildSystem otherwise there are essentially two different repositories evolving over time with different things in each one. That is freaking insane! Who designed this stupid subrepo shit? It is completely garbage if what you say is true. Barry

1 0