I'm thinking of how to handle this bug:
https://bugs.launchpad.net/ffc/+bug/787010
I see two solutions:
1. Handle parameters with dynamical type in C++ (fairly easy to add).
2. Not use parameters that may change type in FFC (from "auto" to an
int).
--
Anders
__
FFC can generated *very* large files with the tensor contraction
approach, especially when auxiliary problems like error estimation are
used. This makes compilation slow, and possibly fail.
The array A in the generated code often has a lot of zeroes. Would it be
sensible to
1. Initialise A to zer
On 6 July 2011 13:17, Garth N. Wells wrote:
> FFC can generated *very* large files with the tensor contraction
> approach, especially when auxiliary problems like error estimation are
> used. This makes compilation slow, and possibly fail.
>
> The array A in the generated code often has a lot of z
On 6 July 2011 14:44, Kristian Ølgaard wrote:
> On 6 July 2011 13:17, Garth N. Wells wrote:
>> FFC can generated *very* large files with the tensor contraction
>> approach, especially when auxiliary problems like error estimation are
>> used. This makes compilation slow, and possibly fail.
>>
>>
On Wed, Jul 06, 2011 at 12:17:15PM +0100, Garth N. Wells wrote:
> FFC can generated *very* large files with the tensor contraction
> approach, especially when auxiliary problems like error estimation are
> used. This makes compilation slow, and possibly fail.
>
> The array A in the generated code o
On Jul 6, 2011, at 1:54, Anders Logg wrote:
> I'm thinking of how to handle this bug:
>
> https://bugs.launchpad.net/ffc/+bug/787010
>
> I see two solutions:
>
> 1. Handle parameters with dynamical type in C++ (fairly easy to add).
Not sure I like this. It is nice to have a strongly typed reg
6 matches
Mail list logo