From: Nasser M. A. <nas...@mc...> - 2008-08-29 05:50:28
|
Hello: I have a nonlinear time-dependent PDE system where the individual variables compose a second order tensor. This form is convenient for simulation, but not for interpreting the data, for which I need the eigenvalues and vectors of the tensor. I don't really have the choice of using Octave to do this post-simulation in that I am using adaptive meshing and a huge dataset that requires parallelization. I'm trying to figure out a sensible way to modify my Libmesh implementation (using FEMSystem) to do this but I'm not sure how to proceed. Is there a way to tell Libmesh that certain variables are neither time-evolving or constraints, so that they are not accounted for in the factorization? So I would start with a FEMsystem with all of the tensor components, eigenvalues, and eigenvector components in the same system. Would I then just implement the postprocessing functions and use the Gnu Scientific Library to compute the eigenvalues/vectors based upon the tensor components computed from the current solution. Please give me a few pointers... -- Nasser Mohieddin Abukhdeir Graduate Student (Materials Modeling Research Group) McGill University - Department of Chemical Engineering http://webpages.mcgill.ca/students/nabukh/web/ http://mmrg.chemeng.mcgill.ca/ |
From: Benjamin K. <ben...@na...> - 2008-08-29 13:16:15
|
> Is there a way to tell Libmesh that certain variables are neither > time-evolving or constraints, so that they are not accounted for in the > factorization? So I would start with a FEMsystem with all of the tensor > components, eigenvalues, and eigenvector components in the same system. Since they are computed as a post-processing step from the tensor components you definitely do not want them coupled in the linear system, so that calls for another system. I have a somewhat similar issue in my compressible NS stuff. I solve a large implicit system for (rho, rho*u, rho*v, rho*w, rho*E) -- the so-called conserved variables. But other places in the code, and for visualization, I really want access to (P, u, v, T, M) -- primitive variables + Mach number. And I don't want them making my linear system any bigger. > Would I then just implement the postprocessing functions and use the Gnu > Scientific Library to compute the eigenvalues/vectors based upon the > tensor components computed from the current solution. > > Please give me a few pointers... What I do is add an ExplicitSystem to my EquationSystems. I then fill it with these "auxiliary variables." The benefit of this approach is (i) there is no matrix allocation for these explicit variables, and (ii) they can be output to visualization formats in the usual way. You can either provide your own assemble function for the auxiliary system which does the processing you want, or do it at the beginning/end of the assemble of the primary system. -Ben |
From: Nasser M. A. <nas...@mc...> - 2008-08-31 22:48:27
|
So, here is what I am implementing to concurrently post-process my data: 1) added an ExplicitSystem that contains my postprocessing variables to the EquationSystem instance 2) implemented the FEMSystem::element_postprocess() function in my primary system (tensor variables) and then added a FEMSystem::postprocess() call after every FEMSystem::solve() in my main function 3) What I am working on now is to implement the very convenient FEMSystem::elem_subsolutions variable but for the postprocessing ExplicitSystem class. Does this make sense? It seems like the cleanest way to get access to the postprocessing variables that correspond to the primary variables on the element of interest. Nasser Mohieddin Abukhdeir Graduate Student (Materials Modeling Research Group) McGill University - Department of Chemical Engineering http://webpages.mcgill.ca/students/nabukh/web/ http://mmrg.chemeng.mcgill.ca/ |
From: Roy S. <ro...@st...> - 2008-09-01 00:58:14
|
On Sun, 31 Aug 2008, Nasser Mohieddin Abukhdeir wrote: > 3) What I am working on now is to implement the very convenient > FEMSystem::elem_subsolutions variable but for the postprocessing > ExplicitSystem class. Does this make sense? It seems like the cleanest > way to get access to the postprocessing variables that correspond to the > primary variables on the element of interest. This definitely makes sense, and it is probably the easiest way for you to go, but: One design change I've been considering would be to have DiffSystem (and thus FEMSystem) inherit directly from System rather than from ImplicitSystem, so that the FEMSystem could manage it's own jacobian matrix. The sparse matrix creation could then be disabled if the user requested it. My interest in this would be to make FEMSystem a little more attractive for use in jacobian-free solves... that's not such an immediate concern that I plan to do it myself any time soon, but since it would be useful for you too, if you wanted to make the changes I'd be happy to accept a patch. --- Roy |
From: Nasser M. A. <nas...@mc...> - 2008-09-01 08:42:01
|
thanks (everyone) for the help, adding the include took care of the problem, I won't make that mistake again.. As for the inheritance change, that does make alot of sense, I am just not confident enough right now to implement this change with my newbie C++ skills. I think I have a decent grasp on a postprocessing using ExplicitSystem so I'd like to start a DiffSystem section on the wiki and add this as an example. Also, I'm using the Gnu Scientific Library to calculate the eigenvalues/vectors. I have used this library alot in the past (years ago), is this the best way to go for my postprocessing tasks? Nasser Mohieddin Abukhdeir Graduate Student (Materials Modeling Research Group) McGill University - Department of Chemical Engineering http://webpages.mcgill.ca/students/nabukh/web/ http://mmrg.chemeng.mcgill.ca/ Roy Stogner wrote: > On Sun, 31 Aug 2008, Nasser Mohieddin Abukhdeir wrote: > > >> 3) What I am working on now is to implement the very convenient >> FEMSystem::elem_subsolutions variable but for the postprocessing >> ExplicitSystem class. Does this make sense? It seems like the cleanest >> way to get access to the postprocessing variables that correspond to the >> primary variables on the element of interest. >> > > This definitely makes sense, and it is probably the easiest way for > you to go, but: > > One design change I've been considering would be to have DiffSystem > (and thus FEMSystem) inherit directly from System rather than from > ImplicitSystem, so that the FEMSystem could manage it's own jacobian > matrix. The sparse matrix creation could then be disabled if the user > requested it. My interest in this would be to make FEMSystem a little > more attractive for use in jacobian-free solves... that's not such an > immediate concern that I plan to do it myself any time soon, but since > it would be useful for you too, if you wanted to make the changes I'd > be happy to accept a patch. > --- > Roy > |
From: John P. <jwp...@gm...> - 2008-09-01 15:44:58
|
On Mon, Sep 1, 2008 at 3:41 AM, Nasser Mohieddin Abukhdeir <nas...@mc...> wrote: > thanks (everyone) for the help, adding the include took care of the > problem, I won't make that mistake again.. > > As for the inheritance change, that does make alot of sense, I am just > not confident enough right now to implement this change with my newbie > C++ skills. I think I have a decent grasp on a postprocessing using > ExplicitSystem so I'd like to start a DiffSystem section on the wiki and > add this as an example. > > Also, I'm using the Gnu Scientific Library to calculate the > eigenvalues/vectors. I have used this library alot in the past (years > ago), is this the best way to go for my postprocessing tasks? > It sounds like you are solving a bunch of small dense eigenproblems, so yeah if the GSL is already working for you then that's probably the way to go. For large spare eigenproblems, SLEPc has worked well for me in the past. -- John |