- Sep 05, 2018
-
-
Robert K authored
-
- Sep 03, 2018
-
-
Robert K authored
-
- Nov 22, 2017
-
-
Robert K authored
-
- Aug 07, 2017
-
-
Robert K authored
-
- Jul 31, 2017
-
-
Stefan Girke authored
-
- Jul 24, 2017
-
-
Stefan Girke authored
-
Stefan Girke authored
-
- Jun 23, 2017
-
-
Tobias Malkmus authored
This should resolve issue #1
-
- May 16, 2017
-
-
Stefan Girke authored
-
- May 08, 2017
-
-
Stefan Girke authored
-
- May 05, 2017
-
-
Stefan Girke authored
-
Stefan Girke authored
-
Stefan Girke authored
-
Stefan Girke authored
-
Stefan Girke authored
-
Stefan Girke authored
These changes were needed inside the assembly of the primal matrix to allow additional discrete functions forwarding to the assembler which forwards them to the model which is then able to evaluate these discrete functions. Mainly, there are two approaches: 1. Use the whole pass stuff (InsertFunctionPass), model caller etc. 2. exchange the std::vector<std::vector<> > structure of evaluation values by a std::vector< std::tuple< 'anything'..., std::vector<> > > structure. and prepare data on your own. I followed the second approach which will help to distinct between pass-based operators and the tuple structure, mainly given by algorithm creator. That means: The algorithm creator can still prescribe some variadic tuples of additional values, the operator decides (based on his implementation) whether to use passes or handle these information on his own - but the analytical models do not care about the operators decision. Short overview on main features/changes: - Better distinction between a quadrature context (spational information) and their corresponding local evaluation regarding this context - no time()-method anymore: time has to be taken from the analytical model, now. - Local Evaluations are constructed once (for each element) and each called sub routine is now able to 'unpack' regarding up to three different attributes * quadrature point (has to be an unsigned int/long unsigned int) * passId/Id of tuple (has to be a std::integral_const<int,.> value) * basis function number (has to be a signed int) via sub script operator[] -> disadvantages: always mind the right type, implicit type conversion is disabled -> advantages: possible to unpack recursively and also return vector/matrix like structures. No conversion (ala RangeValues in primalmatrix etc.) needed anymore Known issue: performance loss: This will not be avoidable 100% as models are more general know, but I will have a look on that later on
-
Stefan Girke authored
-
Stefan Girke authored
-
Stefan Girke authored
-
Stefan Girke authored
-
Stefan Girke authored
-
Stefan Girke authored
-
- Mar 12, 2017
-
-
Robert K authored
-
- Feb 24, 2017
-
-
Robert K authored
This is enough for initialization of singleton variables.
-
- Dec 09, 2016
-
-
Stefan Girke authored
-
- Nov 14, 2016
-
-
Tobias Malkmus authored
-
- Oct 05, 2016
-
-
Robert K authored
-
- Aug 25, 2016
-
-
Robert K authored
-
- Aug 23, 2016
-
-
Robert K authored
-
- Aug 19, 2016
-
-
Stefan Girke authored
-
- Aug 07, 2016
-
-
Robert K authored
-
- Aug 03, 2016
- Jul 31, 2016
-
-
Robert K authored
-
- Jul 07, 2016
-
-
Stefan Girke authored
-
- May 08, 2016
-
-
Robert K authored
-
- Feb 24, 2016
-
-
Robert K authored
-
- Feb 11, 2016
-
-
Stefan Girke authored
-
- Feb 05, 2016
-
-
Stefan Girke authored
-
Stefan Girke authored
-