> On Apr 11, 2019, at 9:07 PM, Mark Adams via petsc-dev
> wrote:
>
> Interesting, nice work.
>
> It would be interesting to get the flop counters working.
>
> This looks like GMG, I assume 3D.
>
> The degree of parallelism is not very realistic. You should probably run a
> 10x smaller pro
Interesting, nice work.
It would be interesting to get the flop counters working.
This looks like GMG, I assume 3D.
The degree of parallelism is not very realistic. You should probably run a
10x smaller problem, at least, or use 10x more processes. I guess it does
not matter. This basically like
Excellent! Thanks
Barry
> On Apr 11, 2019, at 6:08 PM, Fande Kong via petsc-dev
> wrote:
>
> Hi Developers,
>
> I just want to share a good news. It is known PETSc-ptap-scalable is taking
> too much memory for some applications because it needs to build intermediate
> data structur
Lawrence Mitchell via petsc-dev writes:
>> On 11 Apr 2019, at 21:02, Matthew Knepley via petsc-dev
>> wrote:
>>
>> Jed, should we be doing this? My first impression is that our builds catch a
>> lot of configure errors so we do not want it.
>
> We still configure and build firedrake in the te
> On 11 Apr 2019, at 21:02, Matthew Knepley via petsc-dev
> wrote:
>
> Jed, should we be doing this? My first impression is that our builds catch a
> lot of configure errors so we do not want it.
We still configure and build firedrake in the tests. This is just for
downstream applications
You mean using it for all the dependencies? Most commits don't change
anything in the config/ tree, so we don't need to re-run configure. But
they do generally change the source so we'd still need to build PETSc.
We could set up caching to only rebuild what is needed, but the details
of the cachi
