May 2014 - discuss - mailman3.cels.anl.gov

problem when configure mpich
by Yan Bai 07 May '14

07 May '14

Hello I was trying to install mpich-3.1 but stopped at the first step: configuration. The Fortran compiler I have is absoft. I tried both the configuration command given by Readme file of mpich-3.1 and the configuration line given by Absoft. Both have the following error message: configure: error: The selected Fortran 90 compiler /Applications/Absoft11.5/bin/af90 does not work with the selected Fortran 77 compiler /Applications/Absoft11.5/bin/af77. Use the environment variables FC and F77 respectively to select compatible Fortran compilers. The check here tests to see if a main program compiled with the Fortran 90 compiler can link with a subroutine compiled with the Fortran 77 compiler. Attached please find the log files. I really appreciate your help! Best regards Yan ------------------ Yan Bai 216 Harkness Hall, RC 270156 Department of Economics University of Rochester 585.275.4196 (office) 585.256.2309 (fax) yanbai06(a)gmail.com https://sites.google.com/site/yanbai06/

1 0

Re: [mpich-discuss] MPICH datatype memory utilization and low memory system
by Jed Brown 07 May '14

07 May '14

Rob Latham <robl(a)mcs.anl.gov> writes: > ON blue gene... well you maybe can guess where I'm going with this. > MPICH will use quite a bit of memory to describe 16 million points: > about 200 MiB (4 bytes for each index, 8 bytes for each offset). > > there isn't 200 MiB of extra memory on some configurations of Blue Gene. > > What options does one have when trying to efficiently describe > unstructured data, though? How large is the data that this unstructured representation is describing? Usually there will be element connectivity and several elements are adjacent to each vertex, so the relative overhead of the MPICH datatypes may not be high. The index/offset arrays can probably be compressed, though that only reduces peak memory usage if you specify and free the uncompressed arrays before other allocations.

1 0

MPICH datatype memory utilization and low memory system
by Rob Latham 07 May '14

07 May '14

We've encouraged our HDF5 friends to use MPI datatypes to describe their I/O with the promise that "we'll fix it" if they find problems in the MPI implementation. the MOAB folks use HDF5 to store and read their unstructured mesh data, and so HDF5 is using MPI_Type_hindexed to describe these approximately 16 million points. ON blue gene... well you maybe can guess where I'm going with this. MPICH will use quite a bit of memory to describe 16 million points: about 200 MiB (4 bytes for each index, 8 bytes for each offset). there isn't 200 MiB of extra memory on some configurations of Blue Gene. What options does one have when trying to efficiently describe unstructured data, though? ==rob -- Rob Latham Mathematics and Computer Science Division Argonne National Lab, IL USA

1 0

Re: [mpich-discuss] mpich3 3.0.4 and binding on four socket nodes
by Kenneth Raffenetti 07 May '14

07 May '14

There was significant improvement to the process binding features in the MPICH 3.1 release. Can you build that version and see if it fixes the issue? Ken On 05/07/2014 02:25 PM, Susan A. Schwarz wrote: > I am using mpich3 3.0.4 built with Intel 13.0 compilers on Centos 6.5. I > am trying to use the 'bind-to core' and 'map-by core:2' options to > mpiexec. I am able to run this successfully on nodes in my cluster where > there are 2 sockets. However, when I try to run it on a 4 socket node > with 12 cores per socket, I get the following errors: > > [proxy:0:0@f02] get_nbobjs_by_type > (./tools/topo/hwloc/topo_hwloc.c:189): assert (nb % x == 0) failed > [proxy:0:0@f02] handle_bitmap_binding > (./tools/topo/hwloc/topo_hwloc.c:450): unable to get number of objects > [proxy:0:0@f02] HYDT_topo_hwloc_init > (./tools/topo/hwloc/topo_hwloc.c:527): error binding with bind "core" > and map "core:2" > [proxy:0:0@f02] HYDT_topo_init (./tools/topo/topo.c:60): unable to > initialize hwloc > [proxy:0:0@f02] launch_procs (./pm/pmiserv/pmip_cb.c:520): unable to > initialize process topology > [proxy:0:0@f02] HYD_pmcd_pmip_control_cmd_cb > (./pm/pmiserv/pmip_cb.c:893): launch_procs returned error > [proxy:0:0@f02] HYDT_dmxu_poll_wait_for_event > (./tools/demux/demux_poll.c:77): callback returned error status > [proxy:0:0@f02] main (./pm/pmiserv/pmip.c:206): demux engine error > waiting for event > [mpiexec@f02] control_cb (./pm/pmiserv/pmiserv_cb.c:202): assert > (!closed) failed > [mpiexec@f02] HYDT_dmxu_poll_wait_for_event > (./tools/demux/demux_poll.c:77): callback returned error status > [mpiexec@f02] HYD_pmci_wait_for_completion > (./pm/pmiserv/pmiserv_pmci.c:197): error waiting for event > [mpiexec@f02] main (./ui/mpich/mpiexec.c:331): process manager error > waiting for completion > > Any idea what could be causing this problem? > > Susan Schwarz > Research Computing > Dartmouth > > > > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss

1 0

mpich3 3.0.4 and binding on four socket nodes
by Susan A. Schwarz 07 May '14

07 May '14

I am using mpich3 3.0.4 built with Intel 13.0 compilers on Centos 6.5. I am trying to use the 'bind-to core' and 'map-by core:2' options to mpiexec. I am able to run this successfully on nodes in my cluster where there are 2 sockets. However, when I try to run it on a 4 socket node with 12 cores per socket, I get the following errors: [proxy:0:0@f02] get_nbobjs_by_type (./tools/topo/hwloc/topo_hwloc.c:189): assert (nb % x == 0) failed [proxy:0:0@f02] handle_bitmap_binding (./tools/topo/hwloc/topo_hwloc.c:450): unable to get number of objects [proxy:0:0@f02] HYDT_topo_hwloc_init (./tools/topo/hwloc/topo_hwloc.c:527): error binding with bind "core" and map "core:2" [proxy:0:0@f02] HYDT_topo_init (./tools/topo/topo.c:60): unable to initialize hwloc [proxy:0:0@f02] launch_procs (./pm/pmiserv/pmip_cb.c:520): unable to initialize process topology [proxy:0:0@f02] HYD_pmcd_pmip_control_cmd_cb (./pm/pmiserv/pmip_cb.c:893): launch_procs returned error [proxy:0:0@f02] HYDT_dmxu_poll_wait_for_event (./tools/demux/demux_poll.c:77): callback returned error status [proxy:0:0@f02] main (./pm/pmiserv/pmip.c:206): demux engine error waiting for event [mpiexec@f02] control_cb (./pm/pmiserv/pmiserv_cb.c:202): assert (!closed) failed [mpiexec@f02] HYDT_dmxu_poll_wait_for_event (./tools/demux/demux_poll.c:77): callback returned error status [mpiexec@f02] HYD_pmci_wait_for_completion (./pm/pmiserv/pmiserv_pmci.c:197): error waiting for event [mpiexec@f02] main (./ui/mpich/mpiexec.c:331): process manager error waiting for completion Any idea what could be causing this problem? Susan Schwarz Research Computing Dartmouth

1 0

Re: [mpich-discuss] MPE2 and OpenMPI 1.8.1
by Steven Wright 06 May '14

06 May '14

Hi, The API for OpenMPI has changed at version 1.8.1 (in that many parameters have been made const). This breaks compatibility with MPE when using GCC (though Intel reports these as warnings, rather than errors). Attached is a patch to make MPE2 compliant with the current MPI3.0 specification (and therefore build correctly with OpenMPI 1.8.1). Apply in mpe2-1.3.0 directory: ~/mpe2-1.3.0$ patch -p1 < ompi-1.8.1.patch Thanks, Steven -- Steven Wright CS202 High Performance and Scientific Computing Performance Computing and Visualisation Department of Computer Science University of Warwick Tel: +44 (0)24 7657 3775

1 0

Re: [mpich-discuss] Help for installing mpich
by Rob Latham 06 May '14

06 May '14

On 05/05/2014 04:57 PM, Kenneth Raffenetti wrote: > Steve, > > It looks like the iptables firewall may be active and preventing MPICH > from communicating between nodes. You should be able to confirm this by > temporarily disabling the firewalls (sudo /etc/init.d/iptables stop) on > the involved nodes. what if steve doesn't have privileges to do so? He can SSH, so there is some ssh tunneling magic he can set up to work around firewalls, right? alas, replace 'tar' with 'ssh tunneling' in this comic and you have me: http://www.xkcd.com/1168/ ==rob > > If that's indeed the case, you may want to permanently disable the > firewalls or configure them to allow a specific port range for MPICH. > The wiki has info on how to tell MPICH which port range to use. > > http://wiki.mpich.org/mpich/index.php/Frequently_Asked_Questions#Q:_How_do_… > > > Ken > > On 05/05/2014 04:39 PM, Rusty Lusk wrote: >> >> >> Hi, can someone help Steve with this problem? >> >> Steve, I am forwarding this to mpich-discuss, which is our >> problem-reporting list. It will probably go first to the excellent Ken >> Raffenetti, who I predict will be able to help. >> >> Rusty >> >> >> Begin forwarded message: >> >>> *From: *"Steven C. Pieper" <spieper(a)anl.gov <mailto:[email protected]>> >>> *Subject: **Help for installing mpich* >>> *Date: *May 5, 2014 at 4:25:13 PM CDT >>> *To: *Ralph Butler <rbutler(a)mtsu.edu <mailto:[email protected]>>, Rusty >>> Lusk <lusk(a)mcs.anl.gov <mailto:[email protected]>> >>> *Reply-To: *<spieper(a)anl.gov <mailto:[email protected]>> >>> >>> I'm trying to build mpich on the theory linux cluster which >>> is scientific Linux 6.2 which is basically Redhat Enterprise 6 >>> >>> I got mpich-3.1 from the download site, did the configure, >>> make, and install (into ~/mpich-install) . This all >>> seemed OK. I made a machine file: >>> >>> theoryl14.phy.anl.gov <http://theoryl14.phy.anl.gov>:2 # 2 processes >>> on l14 >>> theoryl18.phy.anl.gov <http://theoryl18.phy.anl.gov>:3 # 3 processes >>> on l18 >>> >>> If I am on theoryl14, I can run the hostname test on just l14: >>> >>> [theoryl14 mpich-test] mpiexec -f machfile_l14 -n 2 hostname >>> theoryl14.phy.anl.gov <http://theoryl14.phy.anl.gov> >>> theoryl14.phy.anl.gov <http://theoryl14.phy.anl.gov> >>> >>> Similarly, if I put the l18 line first, I can run 3 processes >>> on l18 from l18. >>> >>> However I can't run from l14 to l18 or vice versa: >>> Here I start on l14 and specify 3 processes so it has to do >>> one on l18: >>> >>> [theoryl14 mpich-test] mpiexec -f machfile_l14 -n 3 hostname >>> theoryl14.phy.anl.gov <http://theoryl14.phy.anl.gov> >>> theoryl14.phy.anl.gov <http://theoryl14.phy.anl.gov> >>> [proxy:0:[email protected]] HYDU_sock_connect >>> (/home/pieper/mpich-3.1/src/pm/hydra/utils/sock/sock.c:172): unable to >>> connect from "theoryl18.phy.anl.gov <http://theoryl18.phy.anl.gov>" to >>> "theoryl14.phy.anl.gov <http://theoryl14.phy.anl.gov>" (No route to >>> host) >>> [proxy:0:[email protected]] main >>> (/home/pieper/mpich-3.1/src/pm/hydra/pm/pmiserv/pmip.c:189): unable to >>> connect to server theoryl14.phy.anl.gov >>> <http://theoryl14.phy.anl.gov> at port 48451 (check for firewalls!) >>> ---I hit return here >>> [mpiexec(a)theoryl14.phy.anl.gov] HYDU_sock_write >>> (/home/pieper/mpich-3.1/src/pm/hydra/utils/sock/sock.c:286): write >>> error (Bad file descriptor) >>> [mpiexec(a)theoryl14.phy.anl.gov] HYDU_sock_write >>> (/home/pieper/mpich-3.1/src/pm/hydra/utils/sock/sock.c:286): write >>> error (Bad file descriptor) >>> ---I use ctrl-c. >>> >>> I can ssh without passwords: >>> >>> [theoryl14 mpich-test] ssh theoryl18.phy.anl.gov >>> <http://theoryl18.phy.anl.gov> hostname >>> theoryl18.phy.anl.gov <http://theoryl18.phy.anl.gov> >>> [theoryl14 mpich-test] >>> >>> This ssh went through a tunnel that was already established. >>> >>> So I'm confused. Can one of you help? >>> >>> BTW: Scientific Linux will allow me to download openmpi but not mpich. >>> I guess I'd like to try to use mpich. >>> >>> Thanks, >>> Steve >>> >>> -- >>> Steven C. Pieper:[email protected] >>> Argonne National Laboratory, Physics Division, Bldg. 203, Argonne, IL >>> 60439 >>> Phone: 630-252-4232 Fax -6008 >>> Secretary, Debra Morrison, -4100 >> >> >> >> _______________________________________________ >> discuss mailing list discuss(a)mpich.org >> To manage subscription options or unsubscribe: >> https://lists.mpich.org/mailman/listinfo/discuss >> > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss -- Rob Latham Mathematics and Computer Science Division Argonne National Lab, IL USA

1 0

Re: [mpich-discuss] Help for installing mpich
by Kenneth Raffenetti 05 May '14

05 May '14

Steve, It looks like the iptables firewall may be active and preventing MPICH from communicating between nodes. You should be able to confirm this by temporarily disabling the firewalls (sudo /etc/init.d/iptables stop) on the involved nodes. If that's indeed the case, you may want to permanently disable the firewalls or configure them to allow a specific port range for MPICH. The wiki has info on how to tell MPICH which port range to use. http://wiki.mpich.org/mpich/index.php/Frequently_Asked_Questions#Q:_How_do_… Ken On 05/05/2014 04:39 PM, Rusty Lusk wrote: > > > Hi, can someone help Steve with this problem? > > Steve, I am forwarding this to mpich-discuss, which is our > problem-reporting list. It will probably go first to the excellent Ken > Raffenetti, who I predict will be able to help. > > Rusty > > > Begin forwarded message: > >> *From: *"Steven C. Pieper" <spieper(a)anl.gov <mailto:[email protected]>> >> *Subject: **Help for installing mpich* >> *Date: *May 5, 2014 at 4:25:13 PM CDT >> *To: *Ralph Butler <rbutler(a)mtsu.edu <mailto:[email protected]>>, Rusty >> Lusk <lusk(a)mcs.anl.gov <mailto:[email protected]>> >> *Reply-To: *<spieper(a)anl.gov <mailto:[email protected]>> >> >> I'm trying to build mpich on the theory linux cluster which >> is scientific Linux 6.2 which is basically Redhat Enterprise 6 >> >> I got mpich-3.1 from the download site, did the configure, >> make, and install (into ~/mpich-install) . This all >> seemed OK. I made a machine file: >> >> theoryl14.phy.anl.gov <http://theoryl14.phy.anl.gov>:2 # 2 processes >> on l14 >> theoryl18.phy.anl.gov <http://theoryl18.phy.anl.gov>:3 # 3 processes >> on l18 >> >> If I am on theoryl14, I can run the hostname test on just l14: >> >> [theoryl14 mpich-test] mpiexec -f machfile_l14 -n 2 hostname >> theoryl14.phy.anl.gov <http://theoryl14.phy.anl.gov> >> theoryl14.phy.anl.gov <http://theoryl14.phy.anl.gov> >> >> Similarly, if I put the l18 line first, I can run 3 processes >> on l18 from l18. >> >> However I can't run from l14 to l18 or vice versa: >> Here I start on l14 and specify 3 processes so it has to do >> one on l18: >> >> [theoryl14 mpich-test] mpiexec -f machfile_l14 -n 3 hostname >> theoryl14.phy.anl.gov <http://theoryl14.phy.anl.gov> >> theoryl14.phy.anl.gov <http://theoryl14.phy.anl.gov> >> [proxy:0:[email protected]] HYDU_sock_connect >> (/home/pieper/mpich-3.1/src/pm/hydra/utils/sock/sock.c:172): unable to >> connect from "theoryl18.phy.anl.gov <http://theoryl18.phy.anl.gov>" to >> "theoryl14.phy.anl.gov <http://theoryl14.phy.anl.gov>" (No route to host) >> [proxy:0:[email protected]] main >> (/home/pieper/mpich-3.1/src/pm/hydra/pm/pmiserv/pmip.c:189): unable to >> connect to server theoryl14.phy.anl.gov >> <http://theoryl14.phy.anl.gov> at port 48451 (check for firewalls!) >> ---I hit return here >> [mpiexec(a)theoryl14.phy.anl.gov] HYDU_sock_write >> (/home/pieper/mpich-3.1/src/pm/hydra/utils/sock/sock.c:286): write >> error (Bad file descriptor) >> [mpiexec(a)theoryl14.phy.anl.gov] HYDU_sock_write >> (/home/pieper/mpich-3.1/src/pm/hydra/utils/sock/sock.c:286): write >> error (Bad file descriptor) >> ---I use ctrl-c. >> >> I can ssh without passwords: >> >> [theoryl14 mpich-test] ssh theoryl18.phy.anl.gov >> <http://theoryl18.phy.anl.gov> hostname >> theoryl18.phy.anl.gov <http://theoryl18.phy.anl.gov> >> [theoryl14 mpich-test] >> >> This ssh went through a tunnel that was already established. >> >> So I'm confused. Can one of you help? >> >> BTW: Scientific Linux will allow me to download openmpi but not mpich. >> I guess I'd like to try to use mpich. >> >> Thanks, >> Steve >> >> -- >> Steven C. Pieper:[email protected] >> Argonne National Laboratory, Physics Division, Bldg. 203, Argonne, IL 60439 >> Phone: 630-252-4232 Fax -6008 >> Secretary, Debra Morrison, -4100 > > > > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss >

1 0

Help for installing mpich
by Rusty Lusk 05 May '14

05 May '14

Hi, can someone help Steve with this problem? Steve, I am forwarding this to mpich-discuss, which is our problem-reporting list. It will probably go first to the excellent Ken Raffenetti, who I predict will be able to help. Rusty Begin forwarded message: > From: "Steven C. Pieper" <spieper(a)anl.gov> > Subject: Help for installing mpich > Date: May 5, 2014 at 4:25:13 PM CDT > To: Ralph Butler <rbutler(a)mtsu.edu>, Rusty Lusk <lusk(a)mcs.anl.gov> > Reply-To: <spieper(a)anl.gov> > > I'm trying to build mpich on the theory linux cluster which > is scientific Linux 6.2 which is basically Redhat Enterprise 6 > > I got mpich-3.1 from the download site, did the configure, > make, and install (into ~/mpich-install) . This all > seemed OK. I made a machine file: > > theoryl14.phy.anl.gov:2 # 2 processes on l14 > theoryl18.phy.anl.gov:3 # 3 processes on l18 > > If I am on theoryl14, I can run the hostname test on just l14: > > [theoryl14 mpich-test] mpiexec -f machfile_l14 -n 2 hostname > theoryl14.phy.anl.gov > theoryl14.phy.anl.gov > > Similarly, if I put the l18 line first, I can run 3 processes > on l18 from l18. > > However I can't run from l14 to l18 or vice versa: > Here I start on l14 and specify 3 processes so it has to do > one on l18: > > [theoryl14 mpich-test] mpiexec -f machfile_l14 -n 3 hostname > theoryl14.phy.anl.gov > theoryl14.phy.anl.gov > [proxy:0:[email protected]] HYDU_sock_connect (/home/pieper/mpich-3.1/src/pm/hydra/utils/sock/sock.c:172): unable to connect from "theoryl18.phy.anl.gov" to "theoryl14.phy.anl.gov" (No route to host) > [proxy:0:[email protected]] main (/home/pieper/mpich-3.1/src/pm/hydra/pm/pmiserv/pmip.c:189): unable to connect to server theoryl14.phy.anl.gov at port 48451 (check for firewalls!) > ---I hit return here > [mpiexec(a)theoryl14.phy.anl.gov] HYDU_sock_write (/home/pieper/mpich-3.1/src/pm/hydra/utils/sock/sock.c:286): write error (Bad file descriptor) > [mpiexec(a)theoryl14.phy.anl.gov] HYDU_sock_write (/home/pieper/mpich-3.1/src/pm/hydra/utils/sock/sock.c:286): write error (Bad file descriptor) > ---I use ctrl-c. > > I can ssh without passwords: > > [theoryl14 mpich-test] ssh theoryl18.phy.anl.gov hostname > theoryl18.phy.anl.gov > [theoryl14 mpich-test] > > This ssh went through a tunnel that was already established. > > So I'm confused. Can one of you help? > > BTW: Scientific Linux will allow me to download openmpi but not mpich. > I guess I'd like to try to use mpich. > > Thanks, > Steve > > -- > Steven C. Pieper: spieper(a)anl.gov > Argonne National Laboratory, Physics Division, Bldg. 203, Argonne, IL 60439 > Phone: 630-252-4232 Fax -6008 > Secretary, Debra Morrison, -4100

1 0

Re: [mpich-discuss] MPI-IO bug
by Rob Latham 03 May '14

03 May '14

On 05/02/2014 05:24 PM, Wei-keng Liao wrote: > Hi, Rob, > > Now we are all clear about the lower bound for indexed data type. > I wonder if the correct solution (at least for calculating n_filetypes) should change > from > n_filetypes = (offset - flat_file->indices[0]) / filetype_extent; > to > n_filetypes = (offset - filetype_lb) / filetype_extent; that's certainly more clear. ==rob > > Wei-keng > > On May 1, 2014, at 6:03 PM, Wei-keng Liao wrote: > >> >> The flattened filetype offset-length lists are: (i.e. flat_file->indices[] and flat_file->blocklens[]) >> rank0: (0, 0) (4, 0) (8, 0) (12, 0) (16, 8) (28, 4) >> rank1: (0, 16) (20, 0) (24, 4) (32, 4) >> >> What should their type extents be? >> >> MPI_Type_extent() returns values below: >> rank 0: filetype_extent == 16 LB == 16 >> rank 1: filetype_extent == 36 LB == 0 >> >> Is this correct? Shouldn't rank 0's extent be 32 and its LB be 0? >> >> If filetype_extent 16 is correct, then the way of calculating n_filetypes (below) is wrong. >> n_filetypes = (offset - flat_file->indices[0]) / filetype_extent; >> >> The divisor should be the "range extent" of flat_file, i.e. >> (flat_file->indices[flat_file->count-1] + flat_file->blocklens[flat_file->count-1]) - flat_file->indices[0] >> >> >> Wei-keng >> >> On May 1, 2014, at 3:22 PM, Rob Latham wrote: >> >>> >>> >>> On 05/01/2014 12:02 PM, Wei-keng Liao wrote: >>>> They are reasonable doubts. >>>> I tested this patch against test/mpi/io/resized.c and src/mpi/romio/test/hindexed.c >>>> >>>> Could you run tests (both MPI and ROMIO) and see if the patch failed for any tests? >>>> At least we will have an idea if it breaks anything first. >>> >>> OK, happy to do so. We've groused about the sparseness of the ROMIO test coverage for 12 years, but it's enough to catch a few things. >>> >>> This change introduces no new test failures, but I think precisely zero tests tile the file view. >>> >>> I still want to better understand how this works >>> >>> the indexed datatype looks like this (view in fixed-with font please) >>> >>> rank 0: |----11-1-| >>> rank 1: |1111--1-1| >>> >>> ADIOI_Calc_my_off_len() should return a list of 3 things for rank 0 and a list of 3 things for rank 1 . For this test, it does the right thing for rank 1, returning 3 offset-length tuples: (0,16) (24,4) (32,4) >>> >>> but rank 0 returns the entirely incorrect >>> (16,12) >>> >>> instead of >>> (0,0) (16, 8) (28, 4) >>> >>> My concern is mostly with tiling, or in the context of Calc_my_off_len, how n_filetypes is computed (there's also filetype_extent, but ROMIO calls the MPI library for that, so I have high confidence it is correct) >>> >>> Fun finding: if I alter your test case to test the effects of tiling a file view -- by resizing the indexed type -- ROMIO handles that just fine without your change. >>> >>> So actually the problem with Calc_my_off_len seems to be that the indexed type puts the underlying file offset at '16', and ROMIO thinks that means the datatype was tiled once -- it seems to be ignoring the lower bound marker. >>> >>> It's just a small tweak to your approach but I'd like to make it a bit more explicit that the flattened representation uses a zero-length item to indicate the LB of the type. What do you think of the attached patch? >>> >>> I'm still not convinced this properly handles tiling but we fix a known issue and can deal with the tiling-when-not-resized issue later. >>> >>> ==rob >>> >>> >>>> >>>> Wei-keng >>>> >>>> On May 1, 2014, at 10:53 AM, Rob Latham wrote: >>>> >>>>> >>>>> >>>>> On 04/09/2014 02:52 PM, Wei-keng Liao wrote: >>>>> >>>>>> >>>>>> The patch below can fix this problem. Hope it does not break other tests. >>>>> >>>>> I'm uncertain about this patch... >>>>> >>>>>> Index: adio/common/ad_read_coll.c >>>>> >>>>> it should have been in the write path, correct >>>>> ? >>>>>> @@ -368,13 +368,16 @@ >>>>>> #endif >>>>>> if (file_ptr_type == ADIO_INDIVIDUAL) { >>>>>> /* Wei-keng reworked type processing to be a bit more >>>>>> efficient */ >>>>>> + for (i=0; i<flat_file->count; i++) /* skip blocklens[] == 0 */ >>>>>> + if (flat_file->blocklens[i] > 0) break; >>>>>> + >>>>> >>>>> the flat_file->blocklens[] array might contain a UB and LB marker. The marker will be stored in the flattened representation with a zero-length element at a particular offset. So if you resize a type, your flattened representation would be like this: >>>>> (offset: 50, length: 0), >>>>> (offset: 100, length: 1024), >>>>> (offset: 200, length: 0) >>>>> >>>>> furthermore, ADIOI_Optimize_flatten will coalesce multiple zero-length elements into one, but will leave the first and last elements alone. >>>>> >>>>>> offset = fd->fp_ind - disp; >>>>>> - n_filetypes = (offset - flat_file->indices[0]) / >>>>>> filetype_extent; >>>>>> + n_filetypes = (offset - flat_file->indices[i]) / >>>>>> filetype_extent; >>>>> >>>>> doesn't this mess up tiling of the file view? >>>>> >>>>> ==rob >>>>> >>>>>> offset -= (ADIO_Offset)n_filetypes * filetype_extent; >>>>>> /* now offset is local to this extent */ >>>>>> >>>>>> /* find the block where offset is located, skip >>>>>> blocklens[i]==0 */ >>>>>> - for (i=0; i<flat_file->count; i++) { >>>>>> + for (; i<flat_file->count; i++) { >>>>>> ADIO_Offset dist; >>>>>> if (flat_file->blocklens[i] == 0) continue; >>>>>> dist = flat_file->indices[i] + flat_file->blocklens[i] >>>>>> - offset; >>>>>> >>>>>> Wei-keng >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> discuss mailing list discuss(a)mpich.org >>>>>> To manage subscription options or unsubscribe: >>>>>> https://lists.mpich.org/mailman/listinfo/discuss >>>>> >>>>> -- >>>>> Rob Latham >>>>> Mathematics and Computer Science Division >>>>> Argonne National Lab, IL USA >>>>> _______________________________________________ >>>>> discuss mailing list discuss(a)mpich.org >>>>> To manage subscription options or unsubscribe: >>>>> https://lists.mpich.org/mailman/listinfo/discuss >>>> >>>> _______________________________________________ >>>> discuss mailing list discuss(a)mpich.org >>>> To manage subscription options or unsubscribe: >>>> https://lists.mpich.org/mailman/listinfo/discuss >>>> >>> >>> -- >>> Rob Latham >>> Mathematics and Computer Science Division >>> Argonne National Lab, IL USA >>> <0001-Better-deal-with-file-view-types-with-lb.patch>_______________________________________________ >>> discuss mailing list discuss(a)mpich.org >>> To manage subscription options or unsubscribe: >>> https://lists.mpich.org/mailman/listinfo/discuss >> >> _______________________________________________ >> discuss mailing list discuss(a)mpich.org >> To manage subscription options or unsubscribe: >> https://lists.mpich.org/mailman/listinfo/discuss > > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss > -- Rob Latham Mathematics and Computer Science Division Argonne National Lab, IL USA

1 0