Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project!

## Re: [Libmesh-users] Navier-Stokes with forcing

 Re: [Libmesh-users] Navier-Stokes with forcing From: Roy Stogner - 2008-01-19 23:48:20 ``` On Sat, 19 Jan 2008, David Knezevic wrote: > Roy and John: Thanks for the suggestions. > >>> Would it be possible to get all the values you'll need from tau_system >>> before-hand? Depending on the size of the problem, and assuming you >>> could also need multiple values per quadrature point, that might not be >>> feasible. I'm not sure how you'd store them all either. >>> >>> The benefit would be you wouldn't have to worry about the initialization >>> states of two different systems at the same time... > > In my case it would be possible to store the tau solution data in a > vector. I'm not sure of the best way to index that vector within > element_time_derivative though. Assuming the same quadrature rule is > used in both systems, I suppose one could keep a counter (as a member > variable in NavierSystem) that is incremented at each new quadrature > point, and use that to index the tau data? Only if you're very clever or very lucky. Half the point of breaking out element_time_derivative, element_constaint, etc. from a global assembly function is that library code is no longer limited to calling them once per element in order. A trapezoidal rule time integration calls each _time_derivative once at both the beginning and the end of the timestep, for example; you'd have to somehow realize that you were hitting each point twice. --- Roy ```

 [Libmesh-users] Navier-Stokes with forcing From: David Knezevic - 2008-01-18 16:52:06 ```Hi, I'm using FEMSystem to solve Navier-Stokes (based on example 18), but in the case I'm looking at there's a forcing term that comes from the solution of another system, call the external system tau_system. I was thinking of adding a pointer to tau_system to NavierSystem and then implementing a tau_interior_value function in NavierSystem, analogous to FEMSystem's interior_value. Does this sound like a sensible approach? Thanks very much, David ```
 Re: [Libmesh-users] Navier-Stokes with forcing From: Roy Stogner - 2008-01-18 17:12:06 ```On Fri, 18 Jan 2008, David Knezevic wrote: > I'm using FEMSystem to solve Navier-Stokes (based on example 18), but in > the case I'm looking at there's a forcing term that comes from the > solution of another system, call the external system tau_system. I was > thinking of adding a pointer to tau_system to NavierSystem and then > implementing a tau_interior_value function in NavierSystem, analogous to > FEMSystem's interior_value. Does this sound like a sensible approach? You could just call tau_system->interior_value(), if the tau_system had been initialized at the same elem that your Navier Stokes system was currently using. If you'd like, you can factor this initialization code out from FEMSystem::assembly (everything from "elem = *el" up to but not including time_solver->element_residual()) into a separate function to make this initialization easier. The question is when to call that separate function... the only reliable way I can see to do so is right before you use a tau value, but that's inefficient (unless you cache the value of the Elem that was last used to initialize tau, and test to see if it's changed before repeating initialization) and it's awkward. Hmm... even if you did it that way, you'd also have to mess around with the quadrature rule in tau_system, to ensure that you were getting values at the integration points you're using in your Navier Stokes system. Perhaps refactoring FEMSystem code is more trouble than it's worth and writing your own function really is the way to go. I'd still make it two functions - a tau_elem_init(Elem &) to handle the dof_indices(), FE::reinit(), etc. calls, so that you do batch calculations rather than trying to evaluate one point at a time. --- Roy ```
 Re: [Libmesh-users] Navier-Stokes with forcing From: John Peterson - 2008-01-18 17:21:46 ```Would it be possible to get all the values you'll need from tau_system before-hand? Depending on the size of the problem, and assuming you could also need multiple values per quadrature point, that might not be feasible. I'm not sure how you'd store them all either. The benefit would be you wouldn't have to worry about the initialization states of two different systems at the same time... -J Roy Stogner writes: > > On Fri, 18 Jan 2008, David Knezevic wrote: > > > I'm using FEMSystem to solve Navier-Stokes (based on example 18), but in > > the case I'm looking at there's a forcing term that comes from the > > solution of another system, call the external system tau_system. I was > > thinking of adding a pointer to tau_system to NavierSystem and then > > implementing a tau_interior_value function in NavierSystem, analogous to > > FEMSystem's interior_value. Does this sound like a sensible approach? > > You could just call tau_system->interior_value(), if the tau_system > had been initialized at the same elem that your Navier Stokes system > was currently using. If you'd like, you can factor this > initialization code out from FEMSystem::assembly (everything from > "elem = *el" up to but not including time_solver->element_residual()) > into a separate function to make this initialization easier. The > question is when to call that separate function... the only reliable > way I can see to do so is right before you use a tau value, but that's > inefficient (unless you cache the value of the Elem that was last used > to initialize tau, and test to see if it's changed before repeating > initialization) and it's awkward. > > Hmm... even if you did it that way, you'd also have to mess around > with the quadrature rule in tau_system, to ensure that you were > getting values at the integration points you're using in your Navier > Stokes system. Perhaps refactoring FEMSystem code is more trouble > than it's worth and writing your own function really is the way to go. > I'd still make it two functions - a tau_elem_init(Elem &) to handle > the dof_indices(), FE::reinit(), etc. calls, so that you do batch > calculations rather than trying to evaluate one point at a time. > --- > Roy ```
 Re: [Libmesh-users] Navier-Stokes with forcing From: David Knezevic - 2008-01-19 22:46:28 ```Roy and John: Thanks for the suggestions. >> Would it be possible to get all the values you'll need from tau_system >> before-hand? Depending on the size of the problem, and assuming you >> could also need multiple values per quadrature point, that might not be >> feasible. I'm not sure how you'd store them all either. >> >> The benefit would be you wouldn't have to worry about the initialization >> states of two different systems at the same time... In my case it would be possible to store the tau solution data in a vector. I'm not sure of the best way to index that vector within element_time_derivative though. Assuming the same quadrature rule is used in both systems, I suppose one could keep a counter (as a member variable in NavierSystem) that is incremented at each new quadrature point, and use that to index the tau data? >>> Hmm... even if you did it that way, you'd also have to mess around >>> with the quadrature rule in tau_system, to ensure that you were >>> getting values at the integration points you're using in your Navier >>> Stokes system. Perhaps refactoring FEMSystem code is more trouble >>> than it's worth and writing your own function really is the way to go. >>> I'd still make it two functions - a tau_elem_init(Elem &) to handle >>> the dof_indices(), FE::reinit(), etc. calls, so that you do batch >>> calculations rather than trying to evaluate one point at a time. This seems like a good approach as well. I'll let y'all know what I end up doing :) Thanks again, David ```
 Re: [Libmesh-users] Navier-Stokes with forcing From: Roy Stogner - 2008-01-19 23:48:20 ``` On Sat, 19 Jan 2008, David Knezevic wrote: > Roy and John: Thanks for the suggestions. > >>> Would it be possible to get all the values you'll need from tau_system >>> before-hand? Depending on the size of the problem, and assuming you >>> could also need multiple values per quadrature point, that might not be >>> feasible. I'm not sure how you'd store them all either. >>> >>> The benefit would be you wouldn't have to worry about the initialization >>> states of two different systems at the same time... > > In my case it would be possible to store the tau solution data in a > vector. I'm not sure of the best way to index that vector within > element_time_derivative though. Assuming the same quadrature rule is > used in both systems, I suppose one could keep a counter (as a member > variable in NavierSystem) that is incremented at each new quadrature > point, and use that to index the tau data? Only if you're very clever or very lucky. Half the point of breaking out element_time_derivative, element_constaint, etc. from a global assembly function is that library code is no longer limited to calling them once per element in order. A trapezoidal rule time integration calls each _time_derivative once at both the beginning and the end of the timestep, for example; you'd have to somehow realize that you were hitting each point twice. --- Roy ```
 Re: [Libmesh-users] Navier-Stokes with forcing From: John Peterson - 2008-01-21 15:45:44 ```David Knezevic writes: > Roy and John: Thanks for the suggestions. > > >> Would it be possible to get all the values you'll need from tau_system > >> before-hand? Depending on the size of the problem, and assuming you > >> could also need multiple values per quadrature point, that might not be > >> feasible. I'm not sure how you'd store them all either. > >> > >> The benefit would be you wouldn't have to worry about the initialization > >> states of two different systems at the same time... > > In my case it would be possible to store the tau solution data in a > vector. I'm not sure of the best way to index that vector within > element_time_derivative though. Assuming the same quadrature rule is > used in both systems, I suppose one could keep a counter (as a member > variable in NavierSystem) that is incremented at each new quadrature > point, and use that to index the tau data? > You might store a std::vector per Elem with the tau_data (vector is indexed by quadrature point) and keep all those vectors in a std::map or another vector as a member variable of the N-S System. If memory is an issue, you could store only the values required for local assembly of the N-S System ... one std::vector for each active local Elem on each CPU most likely. I don't think you'd have any tricky parallel communication to do. In this case, the map makes more sense, using the Elem ids as the keys. Roy has contributed a mapvector class to LibMesh you could look into. -J ```