Dear Konstantinos,
Unfortunately, I won't be able to share the code. But, in general terms,
the differences we see come from our bricks that heavily use assembly with
workspaces and non-linear terms.
Given that you were working on workspaces, do you think you could detect
some different behaviour in one of the standard contact examples of Getfem?
Best regards,
Andriy
On Tue, 12 Mar 2019 at 07:00, Konstantinos Poulios <[email protected]>
wrote:
> Dear Andriy,
>
> Is it possible to share some code for the test case or is it too specific
> to your own internal stuff? Just looking at the commitdiff again I wasn't
> able to identify any too obvious mistake.
>
> Best regards
> Kostas
>
> On Mon, Mar 11, 2019 at 4:46 PM Andriy Andreykiv <
> [email protected]> wrote:
>
>> Found the commit that causes failure of our tests:
>>
>> SHA-1: 2f7396a46dadad266ba882623d300d1a19e274dc
>> * Code cleanup and stricter constness
>> from Konstantinos on 3/3/2019
>>
>> Konstantinos, Yves, could you have a look at it?
>> Thanks,
>> Andriy
>>
>>
>> On Mon, 11 Mar 2019 at 14:02, Andriy Andreykiv <
>> [email protected]> wrote:
>>
>>> Dear Getfem project,
>>>
>>> We started to get convergence problems in our tests after pulling from
>>> the latest master.
>>> When pulling from Yves's commit made on 27/2/2019 with SHA-1:
>>> 4487cec1aa40728704bf4e4f18b342809944ee0d
>>> and commit message "* two small fixes" everything seemed to work.
>>> The type of a problem that we have is a simple cube compression with
>>> finite strain formulation (hence, no contact). With the above
>>> mentioned commit it nicely converges within 8 steps and quadratic
>>> convergence, while with the latest master it barely manages to reduce the
>>> residual.
>>>
>>> I suspect that something changed in the assembly. Several other branches
>>> got merged that day.
>>> I tried to run it on 1 and several threads - no difference, hence it's
>>> not a thread race.
>>> I will continue checking for the specific commit that fails
>>>
>>> Best regards,
>>> Andriy
>>>
>>>
>>>
