It looks like the recent changes which Cody made to threading in MOOSE
definitely reduced the number of errors reported by helgrind for our
simple_diffusion test.
There might be a threading issue remaining with the Singleton class. Below
is the helgrind output I'm currently seeing, and trying to
On Mon, Feb 1, 2016 at 12:53 PM, John Peterson wrote:
>
>
> On Mon, Feb 1, 2016 at 10:27 AM, David Knezevic <
> david.kneze...@akselos.com> wrote:
>
>> On Mon, Feb 1, 2016 at 12:21 PM, John Peterson
>> wrote:
>>
>>>
>>>
>>> On Mon, Feb 1, 2016 at 10:16 AM, David Knezevic <
>>> david.kneze...@aks
On Mon, Feb 1, 2016 at 10:27 AM, David Knezevic
wrote:
> On Mon, Feb 1, 2016 at 12:21 PM, John Peterson
> wrote:
>
>>
>>
>> On Mon, Feb 1, 2016 at 10:16 AM, David Knezevic <
>> david.kneze...@akselos.com> wrote:
>>
>>> On Mon, Feb 1, 2016 at 12:13 PM, Roy Stogner
>>> wrote:
>>>
We oug
On Mon, Feb 1, 2016 at 12:21 PM, John Peterson wrote:
>
>
> On Mon, Feb 1, 2016 at 10:16 AM, David Knezevic <
> david.kneze...@akselos.com> wrote:
>
>> On Mon, Feb 1, 2016 at 12:13 PM, Roy Stogner
>> wrote:
>>
>>>
>>> We ought to just store order internally as an int, change the existing
>>> con
On Mon, Feb 1, 2016 at 10:16 AM, David Knezevic
wrote:
> On Mon, Feb 1, 2016 at 12:13 PM, Roy Stogner
> wrote:
>
>>
>> We ought to just store order internally as an int, change the existing
>> constructors to convert, and add new constructors that take int.
>> ---
>> Roy
>>
>
>
> Sounds good to
On Mon, Feb 1, 2016 at 12:13 PM, Roy Stogner
wrote:
>
> We ought to just store order internally as an int, change the existing
> constructors to convert, and add new constructors that take int.
> ---
> Roy
>
Sounds good to me. The enum Order seems unnecessarily restrictive, so it'd
be good to s
We ought to just store order internally as an int, change the existing
constructors to convert, and add new constructors that take int.
---
Roy
--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM
On Mon, Feb 1, 2016 at 9:54 AM, David Knezevic
wrote:
> I'd like to couple some extra equations to a system using SCALAR variables
> (the extra equations are not based on the mesh). It would be convenient if
> I could do this by adding a SCALAR variable of arbitrary "order" to the
> system. At th
I'd like to couple some extra equations to a system using SCALAR variables
(the extra equations are not based on the mesh). It would be convenient if
I could do this by adding a SCALAR variable of arbitrary "order" to the
system. At the moment order is capped at 43, according to the Order enum,
but
