Screenshot instructions:
Windows
Mac
Red Hat Linux
Ubuntu
Click URL instructions:
Rightclick on ad, choose "Copy Link", then paste here →
(This may not be possible with some types of ads)
From: Kirk, Benjamin (JSCEG) <Benjamin.Kirk1@na...>  20081106 01:01:11
Attachments:
Message as HTML

BTW, without telling me so much that you have to kill me... What are you solving with 9 variables? More importantly, are they all the same FE type? When I first started putting the DofMap together TaylorHood elements were typical, with varying orders for dfferent variables. But in *all* the applications since equal order for all variables has worked fine. The reason I ask is 'cus if you dig around in the DofMap, especially the distribution part, there is a lot of code which could be simplified if you knew a priori all variable types were identical. This is especially the case when we build the graph of the sparse matrix  it should instead be done for one prototypical variable and the pattern for the rest of the matrix can be inferred. That is an n_vars^2 savings on something that happens at each adaptive step. Similarly, constraints are calculated n_vars times too many... I've been thinking about a derived specialization of the DofMap for this special (but common) case. Ben 
From: Derek Gaston <friedmud@gm...>  20081106 15:05:47
Attachments:
Message as HTML

On Nov 5, 2008, at 5:52 PM, Kirk, Benjamin (JSCEG) wrote: > I see your nutty and raise you batshit crazy: > > PETSc allows you to provide your own buffer for storing the local > elements when you create a vector... Does Trilinos have something > similar? If so, I propose we take the implementation in > DistributedVector, push it down into NumericVector, and beef it up. > I believe that if you're careful how you create your data arrays you should be able to do the same for Trilinos. Look at the "View" constructors for Epetra MultiVectors: http://trilinos.sandia.gov/packages/docs/dev/packages/epetra/doc/html/classEpetra__MultiVector.html#z351_2 If you pass Epetra_DataAccess as "View" and pass in a twodimensional array (in our case it would just be one dimensional for a vector) it should just use your places in memory when you pass that Vector to Trilinos stuff. Essentially, you could manage all of your own memory then just wrap it before you pass it off. Derek 
From: Derek Gaston <friedmud@gm...>  20081113 17:36:03
Attachments:
Message as HTML

Ok  I just committed a set of changes that adds capability for computing discrete norms of NumericVectors for the entries corresponding to a variable's dofs. To do this I added 3 new public methods to NumericVector: subset_l2_norm() subset_l1_norm() subset_linfty_norm() They each take a std::set corresponding to the entries to take the norm on. I actually implemented these functions in the base class... but I did leave them virtual in case someone wants to write optimized versions of these for the leaf classes. I also modified (and added a couple of private methods) System::calculate_norm() methods. I'm not wedded to these names... please feel free to rename them. If you see anything wonky in the new code feel free to tear me a new one about it. ;) Derek On Wed, Nov 5, 2008 at 5:27 PM, Derek Gaston <friedmud@...> wrote: > So... after hashing this out with some people around here... I'm now > thinking that the vector multiply and call linear algebra package norm is a > bad idea. Firstly, we have some systems where we're solving up to 9 > variables! That means we'd have to do all of that stuff every time.... not > too mention wasting memory with all of the zeroes hanging around in that > vector.... > > I'm thinking now of a NumericVector::subset_norm() that takes a std::set of > the local dof indices to perform the norm on and a norm type (or we could > make separate norm functions... either way). > > The std::set could easily be created in System::calculate_norm() for each > variable that you want the discrete norm for and then call subset_norm() the > appropriate number of times. > > And here's where it gets nutty: we just do our own damn norm calculation. > It's not like it's rocket science. We do it right in NumericVector using > the interface functions (like operator() ) so that every NumericVector gets > this capability. > > What do you think? > > Derek > > > > On Nov 5, 2008, at 5:03 PM, Roy Stogner wrote: > > >> >> On Wed, 5 Nov 2008, Kirk, Benjamin (JSCEG) wrote: >> >> Could the api allow you to specify the indices from userspace? The >>> reason I ask is because if all your variables are the same type it >>> is pretty easy to figure out the range from the first_local_index, >>> last_local_index, n_vars, and var_num. >>> >>> That's a little hackish to do inside the library... >>> >> >> A *little* hackish? No, requiring the command line option >> "node_major_dofs" to use that coefficient numbering, that was a >> little hackish. *Breaking* that option (as well as TaylorHood >> elements, etc.) would be a *lot* hackish. ;) >> >> But as an optimization which could fall back on my more general code, >> it's a very good idea. Use NumericVector::subrange_norm() only if >> we're using varmajor numbering, and have the DofMap cache the >> first_local_index_var[n] for each variable so we get the range limits >> right even if there's differing FE types in use. >>  >> Roy >> > > 
From: Roy Stogner <roystgnr@ic...>  20081113 18:19:47

On Thu, 13 Nov 2008, Derek Gaston wrote: > Ok  I just committed a set of changes that adds capability for computing > discrete norms of NumericVectors for the entries corresponding to a > variable's dofs. > To do this I added 3 new public methods to NumericVector: > > subset_l2_norm() > subset_l1_norm() > subset_linfty_norm() > > They each take a std::set corresponding to the entries to take the norm > on. How does this work in parallel  pass in a set of only local elements on each processor? I still think we'd have done better to use another NumericVector of coefficients. It would have about the same overhead as std::set in the most common case and would be much more efficient when taking weighted discrete norms. > I also modified (and added a couple of private methods) > System::calculate_norm() methods. > > I'm not wedded to these names... please feel free to rename them. > > If you see anything wonky in the new code feel free to tear me a new one > about it. ;) Can we at least reoptimize the case where the user just wants a discrete norm of the whole vector? I've always used Sobolev norms when I wanted "slow but physically meaningful" and discrete norms when I wanted "fast but hackish", and I'm worried that unnecessarily finding dof indices and summing each variable separately might take away the "fast" part of that.  Roy 
From: Derek Gaston <friedmud@gm...>  20081113 18:57:16
Attachments:
Message as HTML

On Thu, Nov 13, 2008 at 11:19 AM, Roy Stogner <roystgnr@...>wrote: > > On Thu, 13 Nov 2008, Derek Gaston wrote: > > How does this work in parallel  pass in a set of only local elements > on each processor? Yes  note the new local_dof_indices() method on System(). > I still think we'd have done better to use another NumericVector of > coefficients. It would have about the same overhead as std::set in > the most common case and would be much more efficient when taking > weighted discrete norms. Well.... I kind of mocked it up... and just didn't like it. It felt like a lot manipulation just to do something simple. > Can we at least reoptimize the case where the user just wants a > discrete norm of the whole vector? I've always used Sobolev norms > when I wanted "slow but physically meaningful" and discrete norms when > I wanted "fast but hackish", and I'm worried that unnecessarily > finding dof indices and summing each variable separately might take > away the "fast" part of that. If you want the discrete norm of the whole vector just call v.l2_norm() or whatever. If you're talking about possibly detecting that all of the variable weights are 1.0 and calling v.l2_norm() in System::calculate_norm()... that should be possible. I viewed what was there before as wrong since it didn't take the weighting into account at all. Specifically, if you called the calculate_norm() method that takes a variable number and passed in a discrete norm.... you didn't get back the norm of the entries corresponding to that variable... instead you got back the norm of the whole vector (with no warning or anything). Now you get back what you expect. Do you want me to put a check in there to see if all of the variable weights are 1.0 and call l2_norm() (or whatever) directly? Derek 
From: Roy Stogner <roystgnr@ic...>  20081113 19:04:23

On Thu, 13 Nov 2008, Derek Gaston wrote: > If you want the discrete norm of the whole vector just call v.l2_norm() > or whatever. And if I want AdaptiveTimeSolver to use the discrete norm of the whole vector? It's already calling System::calculate_norm(), which did call v.l2_norm(), yesterday... ;) > If you're talking about possibly detecting that all of the variable > weights are 1.0 and calling v.l2_norm() in System::calculate_norm()... > that should be possible. I viewed what was there before as wrong since > it didn't take the weighting into account at all. That's right; it basically assumed that if you wanted a discrete norm, you wanted a global discrete norm. I had my "slow but physical" options and my "fast but nonsense" option, and I didn't expect to want to use anything inbetween. > Specifically, if you called the calculate_norm() method that takes a > variable number and passed in a discrete norm.... you didn't get back the > norm of the entries corresponding to that variable... instead you got > back the norm of the whole vector (with no warning or anything). Now you > get back what you expect. Yes; functionally it's definitely an improvement. > Do you want me to put a check in there to see if all of the variable > weights are 1.0 and call l2_norm() (or whatever) directly? Would you? Or just benchmark and tell me that such an optimization is unnecessary and I'll quit whining.  Roy 
From: Derek Gaston <friedmud@gm...>  20081113 19:07:28

On Nov 13, 2008, at 12:04 PM, Roy Stogner wrote: >> Do you want me to put a check in there to see if all of the variable >> weights are 1.0 and call l2_norm() (or whatever) directly? > > Would you? Or just benchmark and tell me that such an optimization is > unnecessary and I'll quit whining. Heh... I'll implement it... but I do suspect that timewise it makes no difference. Technically it might introduce 1 more parallel communication of a double for each variable in your system past your first one.... but I wouldn't expect that to have much overhead ;) Derek 
From: Roy Stogner <roystgnr@ic...>  20081113 19:13:48

On Thu, 13 Nov 2008, Derek Gaston wrote: > On Nov 13, 2008, at 12:04 PM, Roy Stogner wrote: > >>> Do you want me to put a check in there to see if all of the variable >>> weights are 1.0 and call l2_norm() (or whatever) directly? >> >> Would you? Or just benchmark and tell me that such an optimization is >> unnecessary and I'll quit whining. > > Heh... I'll implement it... but I do suspect that timewise it makes no > difference. Technically it might introduce 1 more parallel communication of > a double for each variable in your system past your first one.... but I > wouldn't expect that to have much overhead ;) I'm more concerned about the time spent finding and building the dof indices sets.  Roy 
From: Derek Gaston <friedmud@gm...>  20081113 21:16:39

On Nov 13, 2008, at 12:13 PM, Roy Stogner wrote: > I'm more concerned about the time spent finding and building the dof > indices sets. Good point... I've now committed some changes so that it will use the full vector norm if all of the weights are 1.0. Let me know if you see something else. Derek 
From: Roy Stogner <roystgnr@ic...>  20081113 21:59:25

On Thu, 13 Nov 2008, Derek Gaston wrote: > On Nov 13, 2008, at 12:13 PM, Roy Stogner wrote: > >> I'm more concerned about the time spent finding and building the dof >> indices sets. > > Good point... > > I've now committed some changes so that it will use the full vector norm if > all of the weights are 1.0. > > Let me know if you see something else. No, it looks good.  Roy 
From: Derek Gaston <friedmud@gm...>  20081106 14:58:09
Attachments:
Message as HTML

Currently, I think we're solving for 7 variables... but we've seen where we could have 9. It's currently something pretty close to what John was solving a while ago: double diffusive convection in porous media... except that we solve for a little more that just convection for one of the terms. They might not always be at the same order... even though they are now. We might start solving it with incompressible flow equations... and we'll need to have first order pressures. But yeah, currently they're all the same order. But I'm not so worried about optimization yet (probably not for another year). Even my application is solving for 5 variables: Solid mechanics displacement in 3D, heat condution and species diffusion. As we add more species that number is going to continue to go up. My application might have a region of compressible flow in it too... and we'll be solving for all of that simultaneously. We are truly doing multiphysics work around here... fully coupled and fully implicit. Derek On Nov 5, 2008, at 6:01 PM, Kirk, Benjamin (JSCEG) wrote: > > BTW, without telling me so much that you have to kill me... > > What are you solving with 9 variables? More importantly, are they > all the same FE type? > > When I first started putting the DofMap together TaylorHood > elements were typical, with varying orders for dfferent variables. > But in *all* the applications since equal order for all variables > has worked fine. > > The reason I ask is 'cus if you dig around in the DofMap, > especially the distribution part, there is a lot of code which could > be simplified if you knew a priori all variable types were > identical. This is especially the case when we build the graph of > the sparse matrix  it should instead be done for one prototypical > variable and the pattern for the rest of the matrix can be > inferred. That is an n_vars^2 savings on something that happens at > each adaptive step. > > Similarly, constraints are calculated n_vars times too many... > > I've been thinking about a derived specialization of the DofMap for > this special (but common) case. > > Ben > 