Tim, How many variables and vectors are in your system?
-Ben On 9/5/08 9:42 AM, "Tim Kroeger" <[EMAIL PROTECTED]> wrote: > Dear Roy, > > On Thu, 4 Sep 2008, Roy Stogner wrote: > >>> I see, you are also calling serial vectors "global vectors" now. >> >> Just one subset of serial vectors: those for which every coefficient >> is valid. > > Okay, so we have parallel and serial vectors, where serial vectors can > be divided into global and non-global vectors. > >>> Does the vector have to decide on its constuction whether it is a parellel, >>> serial or sparse vector? >> >> Currently the constructor makes the decision between serial and >> parallel vector. > > I looked into it and found out (which certainly is well-known to you, > but new to me) that the type of a vector can be changed during its > lifetime by calling init(), although this of course clears the data. > Actually, operator=() uses this trick. > >> In the near term, I'd like to replace non-global >> serial vectors with sparse vectors to get rid of the O(N) allocations >> of zeros. In the long term, I'd like to also replace parallel vectors >> with sparse vectors to get rid of the solution/current_local_solution >> redundancies. > > Very good idea, since this redundancy is always driving me crazy, > because I never know which vector is the correct one to use. But > since your last mail, I am starting to understand this a bit better. > So, writing should be performed to "solution" only, and after > finishing writing, System::update() should be called to reflect things > on "current_local_solution", right? > > I am trying to implement a higher order Runge-Kutta time stepping > scheme that requires a large number of additional vectors (about 8). > I guess the best thing is to make these vectors parallel, because the > only thing I have to do with them is to copy them between each other > and the "solution" vector and/or to multiply them with scalars. > > Also, I see that currently neither the grid nor the data will scale as > expected with respect to memory (as long as ParallelMesh is not > released), because "current_local_solution" is a serial copy of > "solution" (not to mention "old_local_solution" for transient > systems). Well, that's of course the reason for you to say that you > would like to change that in the near. > >>> By the way, if I add additional vectors to a system using add_vector(), I >>> assume they are stored parallel as well, right? >> >> Let me see... I think System postpones the initialization, so that you >> can init() such vectors manually (like TransientSsytem::init_data >> does) to make them serial or parallel as you prefer. > > No, they are initialized in System::init_data() and it's parallel > then. (It's different in TransientSystem, since that does not use > System::add_vector().) Sorry for first asking you and then looking it > up myself. I'm just learning, and I think I did a lot things wrong in > my application. > > Summarizing the remainder of the email, I think I just have to wait > for ParallelMesh to be released, since this will solve at least some > of my problems. > > Best Regards, > > Tim > > -- > Dr. Tim Kroeger Phone +49-421-218-7710 > [EMAIL PROTECTED], [EMAIL PROTECTED] Fax +49-421-218-4236 > > MeVis Research GmbH, Universitaetsallee 29, 28359 Bremen, Germany > > Amtsgericht Bremen HRB 16222 > Geschaeftsfuehrer: Prof. Dr. H.-O. Peitgen > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Libmesh-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/libmesh-users ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Libmesh-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-users
