Re: [deal.II] Thermohydromechanical finite element modeling
Dear Wolfgang Thank you for your support. Good luck and good wishes. Amir On Friday, January 24, 2020 at 10:09:42 PM UTC+3:30, Wolfgang Bangerth wrote: > > On 1/24/20 9:45 AM, amir kiani wrote: > > I am trying to find an FEM library that helps me to model a fully > > coupled THM modeling. > > I want to implement a THM formulation exactly the same as the attached > file. > > Can I use deal.ii for this purpose? > > Yes, but there is no code freely available to the best of my knowledge > that already does what you want to do. But people have implemented the > kind of coupled problem you are looking at many times over. For example, > I have had at least two students in my classes who as a class project > implemented a poroelastic solver -- essentially your hydromechanical > component. Adding a temperature solver is not going to make the problem > conceptually more difficult, it's just a bit of extra work. > > So yes, you can use deal.II! > > Best > W. > > -- > > Wolfgang Bangerth email: bang...@colostate.edu > > www: http://www.math.colostate.edu/~bangerth/ > -- The deal.II project is located at http://www.dealii.org/ For mailing list/forum options, see https://groups.google.com/d/forum/dealii?hl=en --- You received this message because you are subscribed to the Google Groups "deal.II User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to dealii+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/dealii/5a3fe118-07dc-49ad-9618-8d4887668e23%40googlegroups.com.
Re: [deal.II] Extract constant modes slow
On 1/24/20 11:52 AM, Jonathan Russ wrote: > > Since you asked I decided to time each thing individually that I > commented out to make sure I knew which function call was taking so > long. It turns out that I was incorrect before when I said that > extract_constant_modes was slow. I was initializing the preconditioner > immediately afterward for some reason with a zero matrix. This > initialization was the reason for additional time. I apologize for the > misleading title of the topic now and will be more careful next time. :-) You just supported the general rule that even good programmers can't tell where their bottlenecks are without actually putting timers into their codes ;-) Best WB -- Wolfgang Bangerth email: bange...@colostate.edu www: http://www.math.colostate.edu/~bangerth/ -- The deal.II project is located at http://www.dealii.org/ For mailing list/forum options, see https://groups.google.com/d/forum/dealii?hl=en --- You received this message because you are subscribed to the Google Groups "deal.II User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to dealii+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/dealii/8def7187-ab9e-a3e5-d389-22cd2c30a4d9%40colostate.edu.
Re: [deal.II] Thermohydromechanical finite element modeling
On 1/24/20 9:45 AM, amir kiani wrote: > I am trying to find an FEM library that helps me to model a fully > coupled THM modeling. > I want to implement a THM formulation exactly the same as the attached file. > Can I use deal.ii for this purpose? Yes, but there is no code freely available to the best of my knowledge that already does what you want to do. But people have implemented the kind of coupled problem you are looking at many times over. For example, I have had at least two students in my classes who as a class project implemented a poroelastic solver -- essentially your hydromechanical component. Adding a temperature solver is not going to make the problem conceptually more difficult, it's just a bit of extra work. So yes, you can use deal.II! Best W. -- Wolfgang Bangerth email: bange...@colostate.edu www: http://www.math.colostate.edu/~bangerth/ -- The deal.II project is located at http://www.dealii.org/ For mailing list/forum options, see https://groups.google.com/d/forum/dealii?hl=en --- You received this message because you are subscribed to the Google Groups "deal.II User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to dealii+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/dealii/6b8d3eeb-2710-ac42-f0fa-05ebde1c813f%40colostate.edu.
Re: [deal.II] Extract constant modes slow
Professor Bangerth - Thank you for your reply, however, I just seemed to have solved my problem. I had a block system with one vector valued field and one scalar valued field. When I extract the constant modes for the vector valued field it is very fast (using the vector component mask). However, the same operation for the scalar valued field does not perform quickly. I see that simply omitting this step for the scalar valued field has almost no effect on the solution of the scalar valued problem. Therefore I no longer have any issue :) Thank you again for your reply and sorry for taking your time. Jonathan On Friday, January 24, 2020 at 12:49:34 PM UTC-5, Wolfgang Bangerth wrote: > > On 1/23/20 5:00 PM, Jonathan Russ wrote: > > > > I noticed that the Trilinos ML preconditioner accessed through the > > TrilinosWrappers benefits heavily from supplying the constant modes or > > the null-space of the laplace operator. Using the extract_constant_modes > > functionality I notice that this can take quite a bit of time for a > > vector valued problem (with 135,000 dofs on 30 processors this took > > about 7 minutes). I was wondering if there is some way for me to speed > > this calculation up somehow? What affects the calculation the most > > (should I not reorder the dofs, etc)? > > Jonathan -- interesting. We do this in most of our codes, and it has > never come up as a problem. Do you think you could construct a minimal > example that shows this? Just set up a DoFHandler and call > extract_constant_modes(). > > Best > W. > > > -- > > Wolfgang Bangerth email: bang...@colostate.edu > > www: http://www.math.colostate.edu/~bangerth/ > -- The deal.II project is located at http://www.dealii.org/ For mailing list/forum options, see https://groups.google.com/d/forum/dealii?hl=en --- You received this message because you are subscribed to the Google Groups "deal.II User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to dealii+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/dealii/cb642c55-42ee-4305-81f9-d29b67362c15%40googlegroups.com.
Re: [deal.II] Extract constant modes slow
On 1/23/20 5:00 PM, Jonathan Russ wrote: > > I noticed that the Trilinos ML preconditioner accessed through the > TrilinosWrappers benefits heavily from supplying the constant modes or > the null-space of the laplace operator. Using the extract_constant_modes > functionality I notice that this can take quite a bit of time for a > vector valued problem (with 135,000 dofs on 30 processors this took > about 7 minutes). I was wondering if there is some way for me to speed > this calculation up somehow? What affects the calculation the most > (should I not reorder the dofs, etc)? Jonathan -- interesting. We do this in most of our codes, and it has never come up as a problem. Do you think you could construct a minimal example that shows this? Just set up a DoFHandler and call extract_constant_modes(). Best W. -- Wolfgang Bangerth email: bange...@colostate.edu www: http://www.math.colostate.edu/~bangerth/ -- The deal.II project is located at http://www.dealii.org/ For mailing list/forum options, see https://groups.google.com/d/forum/dealii?hl=en --- You received this message because you are subscribed to the Google Groups "deal.II User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to dealii+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/dealii/637bd20a-003e-944f-e0ff-e60d1488b83c%40colostate.edu.
Re: [deal.II] number of cells sharing a line
Nicola,
I would simply do this by
std::mapline(0)), unsigned int> line_count;
for(const auto : tria.active_cell_iterators()) {
for(unsigned int i=0; i< GeometryInfo::lines_per_cell; ++i) {
const it = line_count.find(cell->line(i));
if(it != line_count.end())
*it.second++;
else
line_count[cell->line(i)] = 1;
}
We don’t have access to that information within the iterator.
L.
> On 24 Jan 2020, at 8:39, Nicola Giuliani wrote:
>
> Dear all,
>
> In my code I need to reconstruct the number of cells sharing an edge.
>
> Is there a way to reconstruct this number locally? In principle I would need
> something like to cell->line(1)->n_sharing_cells()?
>
> Bests,
> Nicola
>
> --
> The deal.II project is located at http://www.dealii.org/
> For mailing list/forum options, see
> https://groups.google.com/d/forum/dealii?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "deal.II User Group" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to dealii+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/dealii/8f2dca8c-b6e3-4a33-b203-cea32e5fb8a4%40googlegroups.com.
--
The deal.II project is located at http://www.dealii.org/
For mailing list/forum options, see
https://groups.google.com/d/forum/dealii?hl=en
---
You received this message because you are subscribed to the Google Groups
"deal.II User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to dealii+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/dealii/54C88AA4-EAB0-43CC-BF32-6C47AEA38489%40gmail.com.
