[petsc-dev] VecGetArrayAndMemType
Mark Adams
mfadams at lbl.gov
Thu Jun 24 16:19:16 CDT 2021
On Thu, Jun 24, 2021 at 3:05 PM Matthew Knepley <knepley at gmail.com> wrote:
> On Thu, Jun 24, 2021 at 9:58 AM Mark Adams <mfadams at lbl.gov> wrote:
>
>> OK, I tried again and deleted the arch directory every time:
>>
>
> Okay, this changes the interface for OutputSequenceNumber. It _should_ be
> backwards compatible. The likely error I would think
> is that it thinks you have a timestep at first but not later, however that
> should be an HDF5 error. Maybe it think the timestep is always
> the same and overwrites?
>
* The symptom seems to be that there is only one time step in the file and
it is the last one. So yes, it seems to overwrite one file location over
and over.
* I commented out the 2nd View call in ex1 and the file was only 8 bytes
smaller (eg, the time step). The .xmf file was a bit under 2x bigger.
* Visit "sees" all the time steps. That is, I can step through or run a
movie of all the time steps, but the data is exactly the same at all steps.
I've run longer problems with ex2, for each time step.
Mark
>
> Thanks,
>
> Matt
>
>
>> (base) 09:56 (84933e400a...)|BISECTING ~/Codes/petsc2$ git bisect good
>> d7dd068b66a8daa3a37c9e1556b34bd8def54922 is the first bad commit
>> commit d7dd068b66a8daa3a37c9e1556b34bd8def54922
>> Author: Vaclav Hapla <vaclav.hapla at erdw.ethz.ch>
>> Date: Wed Apr 14 21:22:37 2021 +0200
>>
>> HDF5: Improve timestepping.
>>
>> * add PetscViewerHDF5{Push,Pop,Is}Timestepping to control
>> timestepping mode
>> * write timestepping attribute for datasets and check it on reading
>> * fail gracefully if trying to read non-timestepped dataset in
>> timestepping mode and vice-versa (fix #425)
>> * rewrite src/vec/vec/tutorials/ex19.c to improve coverage for
>> timestepping testing
>>
>> doc/documentation/changes/dev.rst | 19 ++-
>> include/petsc/private/viewerhdf5impl.h | 2 +
>> include/petscviewerhdf5.h | 4 +
>> src/dm/impls/da/gr2.c | 21 ++--
>> src/dm/impls/plex/plexhdf5.c | 25 +++-
>> src/sys/classes/viewer/impls/hdf5/hdf5v.c | 124 ++++++++++++++++++--
>> src/vec/is/is/impls/general/general.c | 10 +-
>> src/vec/is/utils/hdf5io.c | 45 +++++---
>> src/vec/vec/impls/mpi/pdvec.c | 14 ++-
>> src/vec/vec/tutorials/ex19.c | 186
>> +++++++++++++++++-------------
>> src/vec/vec/tutorials/output/ex19_2.out | 0
>> src/vec/vec/tutorials/output/ex19_3.out | 0
>> src/vec/vec/tutorials/output/ex19_4.out | 0
>> 13 files changed, 320 insertions(+), 130 deletions(-)
>> delete mode 100644 src/vec/vec/tutorials/output/ex19_2.out
>> delete mode 100644 src/vec/vec/tutorials/output/ex19_3.out
>> delete mode 100644 src/vec/vec/tutorials/output/ex19_4.out
>>
>> On Thu, Jun 24, 2021 at 7:04 AM Matthew Knepley <knepley at gmail.com>
>> wrote:
>>
>>> On Thu, Jun 24, 2021 at 7:00 AM Mark Adams <mfadams at lbl.gov> wrote:
>>>
>>>> OK, this is what I get with bisect:
>>>>
>>>> (base) 06:54 (c3b2925bfb...)|BISECTING ~/Codes/petsc2$ git bisect good
>>>> The merge base c3b2925bfbe1c0a0b3a69c9a76295d0747e33d47 is bad.
>>>> This means the bug has been fixed between
>>>> c3b2925bfbe1c0a0b3a69c9a76295d0747e33d47 and
>>>> [09da24df01e50defd94bc4f7396f866a808ecea5
>>>> c3b2925bfbe1c0a0b3a69c9a76295d0747e33d47].
>>>>
>>>> (base) 06:56 (v3.15.1) ~/Codes/petsc2$ git checkout
>>>> c3b2925bfbe1c0a0b3a69c9a76295d0747e33d47
>>>> Previous HEAD position was 09da24df01 Increase patchlevel to 3.15.1
>>>> HEAD is now at c3b2925bfb Merge branch 'knepley-main-patch-78504' into
>>>> 'release'
>>>> (base) 06:56 (c3b2925bfb...) ~/Codes/petsc2$
>>>>
>>>
>>> I do not understand. Neither of those commits do anything.
>>>
>>> Matt
>>>
>>>
>>>> On Wed, Jun 23, 2021 at 11:14 PM Junchao Zhang <junchao.zhang at gmail.com>
>>>> wrote:
>>>>
>>>>> Mark,
>>>>> I am not sure what your problem is. If it is a regression, can you
>>>>> bisect it?
>>>>> --Junchao Zhang
>>>>>
>>>>>
>>>>> On Wed, Jun 23, 2021 at 4:04 PM Mark Adams <mfadams at lbl.gov> wrote:
>>>>>
>>>>>> I also tried commenting out the second VecView, so there is just one
>>>>>> step in the file, and the .h5 file is only 8 bytes smaller and the .xmf
>>>>>> file goes from 5373 bytes to 3090 bytes.
>>>>>>
>>>>>> On Wed, Jun 23, 2021 at 4:01 PM Mark Adams <mfadams at lbl.gov> wrote:
>>>>>>
>>>>>>> It is not a device issue but it is a regression.
>>>>>>>
>>>>>>> Landau ex1 is tiny and just calls VecView before and after the
>>>>>>> TSsolve, which is one time step. If you add "*-dm_view hdf5:f.h5
>>>>>>> -vec_view hdf5:f.h5::append -dm_landau_Ez 10.*" to landau/ex1 (see
>>>>>>> below), you get an h5 file with two time steps, as it should be.
>>>>>>> This is a huge electric field, Ez=10, which makes the electron
>>>>>>> distribution (u_e) get visibly pulled off center.
>>>>>>> In Visit, both time steps have identical data that is clearly after
>>>>>>> the solve and not the initial condition (see attached).
>>>>>>>
>>>>>>> I ran this again with -ex1_ts_max_steps 0 and get the expected
>>>>>>> result of two steps/frames with the symmetric initial condition in both.
>>>>>>> THis is correct behavior.
>>>>>>>
>>>>>>> Any ideas?
>>>>>>> Thanks
>>>>>>>
>>>>>>> diff --git a/src/ts/utils/dmplexlandau/tutorials/ex1.c
>>>>>>> b/src/ts/utils/dmplexlandau/tutorials/ex1.c
>>>>>>> index 9e4c8f1b61..31dfda2fad 100644
>>>>>>> --- a/src/ts/utils/dmplexlandau/tutorials/ex1.c
>>>>>>> +++ b/src/ts/utils/dmplexlandau/tutorials/ex1.c
>>>>>>> @@ -66,6 +66,6 @@ int main(int argc, char **argv)
>>>>>>> test:
>>>>>>> suffix: 0
>>>>>>> requires: p4est !complex
>>>>>>> - args: -petscspace_degree 3 -petscspace_poly_tensor 1
>>>>>>> -dm_landau_type p4est -dm_landau_ion_masses 2,4 -dm_landau_ion_charges 1,18
>>>>>>> -dm_landau_thermal_temps 5,5,.5 -dm_landau_n 1.00018,1,1e-5 -dm_landau_n_0
>>>>>>> 1e20 -ex1_ts_monitor -ex1_snes_rtol 1.e-14 -ex1_snes_stol 1.e-14
>>>>>>> -ex1_snes_monitor -ex1_snes_converged_reason -ex1_ts_type arkimex
>>>>>>> -ex1_ts_arkimex_type 1bee -ex1_ts_max_snes_failures -1 -ex1_ts_rtol 1e-1
>>>>>>> -ex1_ts_dt 1.e-1 -ex1_ts_max_time 1 -ex1_ts_adapt_clip .5,1.25
>>>>>>> -ex1_ts_adapt_scale_solve_failed 0.75
>>>>>>> -ex1_ts_adapt_time_step_increase_delay 5 -ex1_ts_max_steps 1 -ex1_pc_type
>>>>>>> lu -ex1_ksp_type preonly -dm_landau_amr_levels_max 7
>>>>>>> -dm_landau_domain_radius 5 -dm_landau_amr_re_levels 0 -dm_landau_re_radius
>>>>>>> 1 -dm_landau_amr_z_refine1 1 -dm_landau_amr_z_refine2 0
>>>>>>> -dm_landau_amr_post_refine 0 -dm_landau_z_radius1 .1 -dm_landau_z_radius2
>>>>>>> .1 -dm_refine 1 -dm_landau_gpu_assembly false
>>>>>>> + args: -petscspace_degree 3 -petscspace_poly_tensor 1
>>>>>>> -dm_landau_type p4est -dm_landau_ion_masses 2,4 -dm_landau_ion_charges 1,18
>>>>>>> -dm_landau_thermal_temps 5,5,.5 -dm_landau_n 1.00018,1,1e-5 -dm_landau_n_0
>>>>>>> 1e20 -ex1_ts_monitor -ex1_snes_rtol 1.e-14 -ex1_snes_stol 1.e-14
>>>>>>> -ex1_snes_monitor -ex1_snes_converged_reason -ex1_ts_type arkimex
>>>>>>> -ex1_ts_arkimex_type 1bee -ex1_ts_max_snes_failures -1 -ex1_ts_rtol 1e-1
>>>>>>> -ex1_ts_dt 1.e-1 -ex1_ts_max_time 1 -ex1_ts_adapt_clip .5,1.25
>>>>>>> -ex1_ts_adapt_scale_solve_failed 0.75
>>>>>>> -ex1_ts_adapt_time_step_increase_delay 5 -ex1_ts_max_steps 1 -ex1_pc_type
>>>>>>> lu -ex1_ksp_type preonly -dm_landau_amr_levels_max 7
>>>>>>> -dm_landau_domain_radius 5 -dm_landau_amr_re_levels 0 -dm_landau_re_radius
>>>>>>> 1 -dm_landau_amr_z_refine1 1 -dm_landau_amr_z_refine2 0
>>>>>>> -dm_landau_amr_post_refine 0 -dm_landau_z_radius1 .1 -dm_landau_z_radius2
>>>>>>> .1 -dm_refine 1 -dm_landau_gpu_assembly false *-dm_view hdf5:f.h5
>>>>>>> -vec_view hdf5:f.h5::append -dm_landau_Ez 10.*
>>>>>>>
>>>>>>> TEST*/
>>>>>>>
>>>>>>> On Wed, Jun 23, 2021 at 1:38 PM Mark Adams <mfadams at lbl.gov> wrote:
>>>>>>>
>>>>>>>> Landau ex1 should work. I will test.
>>>>>>>>
>>>>>>>> On Wed, Jun 23, 2021 at 10:47 AM Matthew Knepley <knepley at gmail.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> On Wed, Jun 23, 2021 at 10:44 AM Junchao Zhang <
>>>>>>>>> junchao.zhang at gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>> Use VecGetArrayRead/Write() to get up-to-date host pointers to
>>>>>>>>>> the vector array.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I think Mark is saying that those are not working. We do call
>>>>>>>>> VecGetArrayRead() in the HDF5 code.
>>>>>>>>>
>>>>>>>>> Mark, it seem like a small broken code is necessary.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>>
>>>>>>>>> Matt
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> --Junchao Zhang
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Wed, Jun 23, 2021 at 9:15 AM Mark Adams <mfadams at lbl.gov>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> First, there seem to be two pages for VecGetArrayAndMemType (one
>>>>>>>>>>> has a pointer to the other).
>>>>>>>>>>>
>>>>>>>>>>> So I need to get a CPU array for HDF5 viewing. Totally broken
>>>>>>>>>>> for devices.
>>>>>>>>>>>
>>>>>>>>>>> I don't find a VecGetArrayCpu[HOST] that does the right thing.
>>>>>>>>>>>
>>>>>>>>>>> Perhaps have VecGetArrayAndMemType return a valid CPU pointer
>>>>>>>>>>> when "mtype==NULL"?
>>>>>>>>>>>
>>>>>>>>>>> Mark
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> What most experimenters take for granted before they begin their
>>>>>>>>> experiments is infinitely more interesting than any results to which their
>>>>>>>>> experiments lead.
>>>>>>>>> -- Norbert Wiener
>>>>>>>>>
>>>>>>>>> https://www.cse.buffalo.edu/~knepley/
>>>>>>>>> <http://www.cse.buffalo.edu/~knepley/>
>>>>>>>>>
>>>>>>>>
>>>
>>> --
>>> What most experimenters take for granted before they begin their
>>> experiments is infinitely more interesting than any results to which their
>>> experiments lead.
>>> -- Norbert Wiener
>>>
>>> https://www.cse.buffalo.edu/~knepley/
>>> <http://www.cse.buffalo.edu/~knepley/>
>>>
>>
>
> --
> What most experimenters take for granted before they begin their
> experiments is infinitely more interesting than any results to which their
> experiments lead.
> -- Norbert Wiener
>
> https://www.cse.buffalo.edu/~knepley/
> <http://www.cse.buffalo.edu/~knepley/>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20210624/0f44c11e/attachment-0001.html>
More information about the petsc-dev
mailing list