Bruno, Thanks, you are right. As always, measure first and then optimize after. No point in optimising stuff that costs nothing...
On Tuesday, January 5, 2021 at 3:15:06 p.m. UTC-5 bruno.t...@gmail.com wrote: > Bruno, > > If you are worry about the cost of looking up though the vtable, I think > that you are stuck using template. So either use 2 or 3 and CRTP. But first > of all, I think that you should profile your code and verify that this is a > problem. There is no point in spending time refactoring your code, if your > are going to gain less than 1%... > > Best, > > Bruno > > On Monday, January 4, 2021 at 3:31:45 PM UTC-5 blais...@gmail.com wrote: > >> Dear all, >> I wish you all an happy new year! >> >> One problem we always end up facing with FEM problems is that, as program >> grow, more and more features are added to the equations. This leads to >> multiple variation of the same equations (for example, Navier-Stokes with >> Newtonian and non-Newtonian viscosity, etc.). In turn, this leads to >> assembly functions for the non-linear systems of equations which branch out >> to multiple possibilities. >> >> I was wondering what is the best approach to deal with multiple >> "switches" in an assembly function. The naïve approach would be to use if >> conditions, but I have a feeling that if they appear down in the assembly >> (for example the loop on dofs), this would lead to significantly higher >> assembly cost because the loops would spend time just checking if. >> >> From experience, I have seen the following approaches: >> 1- If or switches in the assembly routine. Simplest/most versatile way, >> but adds significant overhead >> 2- Template the assembly function with the parameters. I think this would >> lead to zero additional cost, but as the number of parameters grows, this >> can become more and more complex since the various possibilities have to be >> known at compile time. >> 3- Use generic interface objects for common elements (for example a >> viscosity class to calculate viscosity, etc.) and use inheritance to >> specialise the model. I think this could be inefficient because of the need >> to extensively look up through the vtable. >> >> What is the general consensus in the deal.II community on this problem? >> What's the best way to deal with multiple possibilities in the same >> assembly function? I would be very interested in hearing the perspective of >> the ASPECT author since it has such a large range of sub models. >> >> >> -- 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/a501667f-4cb7-4894-9364-fb2eaa47c0ecn%40googlegroups.com.
