From nek5000-users at lists.mcs.anl.gov Mon Jun 3 05:46:23 2013 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 3 Jun 2013 12:46:23 +0200 Subject: [Nek5000-users] Problem with multiple file inut Message-ID: Hi Neks, we want to run a post processing job analyzing further things of our full production job. For output in single file things work well with the following patch of code in the usr file of the analysis program: IF (istep.eq.1) THEN do k=1,xx WRITE(fldfle,'("G1_640.f",I5.5)')k initc(1) = trim(fldfle) call restart(1) ?? do your analysis??.. enddo ENDIF It does the analysis for xx snapshots G1_640.f00001 to G1_640.f000xx that we generated before. Bigger jobs requires multiple file outputs, e.g. here each snapshot goes into 4 separate files G1_640.f0000x to G1_643.f0000x I thought that the corresponding extension should do it: IF (istep.eq.1) THEN do k=1,xx k1=4+k WRITE(fldfle,'("G1_64?.f",I5.5)')k1 initc(1) = trim(fldfle) call restart(4) ?? do your analysis??.. enddo ENDIF the patch of log file (see below) indicates that the program reads G1_640.f00005 to G1_643.f00005 correctly and gets stuck afterwards when trying to read the four files G1_64*.f00006: New CG1-tolerance (RINIT*epsm) = 0.874462285180112059E-17 0.607013350432080170E-25 1 1 Helmholtz VELZ F: 8.7446E-05 1.0000E-06 8.3666E-05 2.0000E+02 1 2 Helmholtz VELZ F: 4.5200E-05 1.0000E-06 8.3666E-05 2.0000E+02 1 3 Helmholtz VELZ F: 3.1000E-05 1.0000E-06 8.3666E-05 2.0000E+02 1 4 Helmholtz VELZ F: 2.4871E-05 1.0000E-06 8.3666E-05 2.0000E+02 1 5 Helmholtz VELZ F: 2.0362E-05 1.0000E-06 8.3666E-05 2.0000E+02 1 6 Helmholtz VELZ F: 1.7312E-05 1.0000E-06 8.3666E-05 2.0000E+02 1 7 Helmholtz VELZ F: 1.4629E-05 1.0000E-06 8.3666E-05 2.0000E+02 1 8 Helmholtz VELZ F: 1.2836E-05 1.0000E-06 8.3666E-05 2.0000E+02 1 9 Helmholtz VELZ F: 1.1274E-05 1.0000E-06 8.3666E-05 2.0000E+02 1 10 Helmholtz VELZ F: 9.7394E-06 1.0000E-06 8.3666E-05 2.0000E+02 1 11 Helmholtz VELZ F: 8.3244E-06 1.0000E-06 8.3666E-05 2.0000E+02 1 12 Helmholtz VELZ F: 6.8927E-06 1.0000E-06 8.3666E-05 2.0000E+02 1 13 Helmholtz VELZ F: 5.5410E-06 1.0000E-06 8.3666E-05 2.0000E+02 1 14 Helmholtz VELZ F: 4.4505E-06 1.0000E-06 8.3666E-05 2.0000E+02 1 15 Helmholtz VELZ F: 3.5729E-06 1.0000E-06 8.3666E-05 2.0000E+02 1 16 Helmholtz VELZ F: 2.8812E-06 1.0000E-06 8.3666E-05 2.0000E+02 1 17 Helmholtz VELZ F: 2.3406E-06 1.0000E-06 8.3666E-05 2.0000E+02 1 18 Helmholtz VELZ F: 1.9136E-06 1.0000E-06 8.3666E-05 2.0000E+02 1 19 Helmholtz VELZ F: 1.5656E-06 1.0000E-06 8.3666E-05 2.0000E+02 1 20 Helmholtz VELZ F: 1.2877E-06 1.0000E-06 8.3666E-05 2.0000E+02 1 21 Helmholtz VELZ F: 1.0656E-06 1.0000E-06 8.3666E-05 2.0000E+02 1 22 Helmholtz VELZ F: 8.8191E-07 1.0000E-06 8.3666E-05 2.0000E+02 1 Hmholtz VELZ: 21 8.8191E-07 8.7446E-05 1.0000E-06 L1/L2 DIV(V) : 2.0122E-21 5.8478E-05 L1/L2 QTL : 0.0000E+00 0.0000E+00 L1/L2 DIV(V)-QTL: 2.0122E-21 5.8478E-05 1 5.0000E-03 2.8596E+00 Fluid done filt amp .0000 .0000 .0000 .0000 .0000 .0000 .0000 .0000 .0000 .0000 .0000 .0500 filt trn 1.0000 1.0000 1.0000 1.0000 1.0000 1.0000 1.0000 1.0000 1.0000 1.0000 1.0000 .9500 1 5.0000E-03 -1.3839E-88 1.0000E+00 -3.9134E-06 3.9717E-06 uz_t_mx Reading checkpoint data 0 1 OPEN: G1_640.f00005 byte swap: F 6.543210030 -0.2931277218E+36 12288 1 OPEN: G1_643.f00005 4096 1 OPEN: G1_641.f00005 8192 1 OPEN: G1_642.f00005 1 2.2370E+02 done :: Read checkpoint data avg data-throughput = -80.6MBps io-nodes = 4 0 1 OPEN: .fld .fld byte_read() :: fopen failure2! Parameter 65 in the rea file is set to 4. Could it be that the initc is not correctly set? Thanks a lot, Joerg. From nek5000-users at lists.mcs.anl.gov Mon Jun 3 06:52:16 2013 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 3 Jun 2013 06:52:16 -0500 (CDT) Subject: [Nek5000-users] Problem with multiple file inut In-Reply-To: Message-ID: Hi Joerg, Most likely -- for some reason, the reading routines get a filename ".fld": 0 1 OPEN: .fld .fld so you might also want to check a value of parameter(67) Best. Aleks ----- Original Message ----- From: nek5000-users at lists.mcs.anl.gov To: nek5000-users at lists.mcs.anl.gov Sent: Monday, June 3, 2013 5:46:23 AM Subject: [Nek5000-users] Problem with multiple file inut Hi Neks, we want to run a post processing job analyzing further things of our full production job. For output in single file things work well with the following patch of code in the usr file of the analysis program: IF (istep.eq.1) THEN do k=1,xx WRITE(fldfle,'("G1_640.f",I5.5)')k initc(1) = trim(fldfle) call restart(1) ?? do your analysis??.. enddo ENDIF It does the analysis for xx snapshots G1_640.f00001 to G1_640.f000xx that we generated before. Bigger jobs requires multiple file outputs, e.g. here each snapshot goes into 4 separate files G1_640.f0000x to G1_643.f0000x I thought that the corresponding extension should do it: IF (istep.eq.1) THEN do k=1,xx k1=4+k WRITE(fldfle,'("G1_64?.f",I5.5)')k1 initc(1) = trim(fldfle) call restart(4) ?? do your analysis??.. enddo ENDIF the patch of log file (see below) indicates that the program reads G1_640.f00005 to G1_643.f00005 correctly and gets stuck afterwards when trying to read the four files G1_64*.f00006: New CG1-tolerance (RINIT*epsm) = 0.874462285180112059E-17 0.607013350432080170E-25 1 1 Helmholtz VELZ F: 8.7446E-05 1.0000E-06 8.3666E-05 2.0000E+02 1 2 Helmholtz VELZ F: 4.5200E-05 1.0000E-06 8.3666E-05 2.0000E+02 1 3 Helmholtz VELZ F: 3.1000E-05 1.0000E-06 8.3666E-05 2.0000E+02 1 4 Helmholtz VELZ F: 2.4871E-05 1.0000E-06 8.3666E-05 2.0000E+02 1 5 Helmholtz VELZ F: 2.0362E-05 1.0000E-06 8.3666E-05 2.0000E+02 1 6 Helmholtz VELZ F: 1.7312E-05 1.0000E-06 8.3666E-05 2.0000E+02 1 7 Helmholtz VELZ F: 1.4629E-05 1.0000E-06 8.3666E-05 2.0000E+02 1 8 Helmholtz VELZ F: 1.2836E-05 1.0000E-06 8.3666E-05 2.0000E+02 1 9 Helmholtz VELZ F: 1.1274E-05 1.0000E-06 8.3666E-05 2.0000E+02 1 10 Helmholtz VELZ F: 9.7394E-06 1.0000E-06 8.3666E-05 2.0000E+02 1 11 Helmholtz VELZ F: 8.3244E-06 1.0000E-06 8.3666E-05 2.0000E+02 1 12 Helmholtz VELZ F: 6.8927E-06 1.0000E-06 8.3666E-05 2.0000E+02 1 13 Helmholtz VELZ F: 5.5410E-06 1.0000E-06 8.3666E-05 2.0000E+02 1 14 Helmholtz VELZ F: 4.4505E-06 1.0000E-06 8.3666E-05 2.0000E+02 1 15 Helmholtz VELZ F: 3.5729E-06 1.0000E-06 8.3666E-05 2.0000E+02 1 16 Helmholtz VELZ F: 2.8812E-06 1.0000E-06 8.3666E-05 2.0000E+02 1 17 Helmholtz VELZ F: 2.3406E-06 1.0000E-06 8.3666E-05 2.0000E+02 1 18 Helmholtz VELZ F: 1.9136E-06 1.0000E-06 8.3666E-05 2.0000E+02 1 19 Helmholtz VELZ F: 1.5656E-06 1.0000E-06 8.3666E-05 2.0000E+02 1 20 Helmholtz VELZ F: 1.2877E-06 1.0000E-06 8.3666E-05 2.0000E+02 1 21 Helmholtz VELZ F: 1.0656E-06 1.0000E-06 8.3666E-05 2.0000E+02 1 22 Helmholtz VELZ F: 8.8191E-07 1.0000E-06 8.3666E-05 2.0000E+02 1 Hmholtz VELZ: 21 8.8191E-07 8.7446E-05 1.0000E-06 L1/L2 DIV(V) : 2.0122E-21 5.8478E-05 L1/L2 QTL : 0.0000E+00 0.0000E+00 L1/L2 DIV(V)-QTL: 2.0122E-21 5.8478E-05 1 5.0000E-03 2.8596E+00 Fluid done filt amp .0000 .0000 .0000 .0000 .0000 .0000 .0000 .0000 .0000 .0000 .0000 .0500 filt trn 1.0000 1.0000 1.0000 1.0000 1.0000 1.0000 1.0000 1.0000 1.0000 1.0000 1.0000 .9500 1 5.0000E-03 -1.3839E-88 1.0000E+00 -3.9134E-06 3.9717E-06 uz_t_mx Reading checkpoint data 0 1 OPEN: G1_640.f00005 byte swap: F 6.543210030 -0.2931277218E+36 12288 1 OPEN: G1_643.f00005 4096 1 OPEN: G1_641.f00005 8192 1 OPEN: G1_642.f00005 1 2.2370E+02 done :: Read checkpoint data avg data-throughput = -80.6MBps io-nodes = 4 0 1 OPEN: .fld .fld byte_read() :: fopen failure2! Parameter 65 in the rea file is set to 4. Could it be that the initc is not correctly set? Thanks a lot, Joerg. _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Mon Jun 3 07:00:15 2013 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 3 Jun 2013 14:00:15 +0200 Subject: [Nek5000-users] Problem with multiple file inut In-Reply-To: References: Message-ID: Hi Aleks, p66 and p67 is set to 0.000E+00 Thanks Am 03.06.2013 um 13:52 schrieb nek5000-users at lists.mcs.anl.gov: > Hi Joerg, > > Most likely -- for some reason, the reading routines get a filename ".fld": > > 0 1 OPEN: .fld > .fld > > so you might also want to check a value of parameter(67) > > Best. > Aleks > > ----- Original Message ----- > From: nek5000-users at lists.mcs.anl.gov > To: nek5000-users at lists.mcs.anl.gov > Sent: Monday, June 3, 2013 5:46:23 AM > Subject: [Nek5000-users] Problem with multiple file inut > > Hi Neks, > > we want to run a post processing job analyzing further things of our full production job. > For output in single file things work well with the following patch of code in the usr file of > the analysis program: > > IF (istep.eq.1) THEN > > do k=1,xx > WRITE(fldfle,'("G1_640.f",I5.5)')k > initc(1) = trim(fldfle) > call restart(1) > > ?? do your analysis??.. > > enddo > > ENDIF > > It does the analysis for xx snapshots G1_640.f00001 to G1_640.f000xx that we generated > before. > > Bigger jobs requires multiple file outputs, e.g. here each snapshot goes into 4 separate files > G1_640.f0000x to G1_643.f0000x > > I thought that the corresponding extension should do it: > > > IF (istep.eq.1) THEN > > do k=1,xx > k1=4+k > WRITE(fldfle,'("G1_64?.f",I5.5)')k1 > initc(1) = trim(fldfle) > call restart(4) > > ?? do your analysis??.. > > enddo > > ENDIF > > > the patch of log file (see below) indicates that the program reads G1_640.f00005 to G1_643.f00005 correctly and > gets stuck afterwards when trying to read the four files G1_64*.f00006: > > > > New CG1-tolerance (RINIT*epsm) = 0.874462285180112059E-17 0.607013350432080170E-25 > 1 1 Helmholtz VELZ F: 8.7446E-05 1.0000E-06 8.3666E-05 2.0000E+02 > 1 2 Helmholtz VELZ F: 4.5200E-05 1.0000E-06 8.3666E-05 2.0000E+02 > 1 3 Helmholtz VELZ F: 3.1000E-05 1.0000E-06 8.3666E-05 2.0000E+02 > 1 4 Helmholtz VELZ F: 2.4871E-05 1.0000E-06 8.3666E-05 2.0000E+02 > 1 5 Helmholtz VELZ F: 2.0362E-05 1.0000E-06 8.3666E-05 2.0000E+02 > 1 6 Helmholtz VELZ F: 1.7312E-05 1.0000E-06 8.3666E-05 2.0000E+02 > 1 7 Helmholtz VELZ F: 1.4629E-05 1.0000E-06 8.3666E-05 2.0000E+02 > 1 8 Helmholtz VELZ F: 1.2836E-05 1.0000E-06 8.3666E-05 2.0000E+02 > 1 9 Helmholtz VELZ F: 1.1274E-05 1.0000E-06 8.3666E-05 2.0000E+02 > 1 10 Helmholtz VELZ F: 9.7394E-06 1.0000E-06 8.3666E-05 2.0000E+02 > 1 11 Helmholtz VELZ F: 8.3244E-06 1.0000E-06 8.3666E-05 2.0000E+02 > 1 12 Helmholtz VELZ F: 6.8927E-06 1.0000E-06 8.3666E-05 2.0000E+02 > 1 13 Helmholtz VELZ F: 5.5410E-06 1.0000E-06 8.3666E-05 2.0000E+02 > 1 14 Helmholtz VELZ F: 4.4505E-06 1.0000E-06 8.3666E-05 2.0000E+02 > 1 15 Helmholtz VELZ F: 3.5729E-06 1.0000E-06 8.3666E-05 2.0000E+02 > 1 16 Helmholtz VELZ F: 2.8812E-06 1.0000E-06 8.3666E-05 2.0000E+02 > 1 17 Helmholtz VELZ F: 2.3406E-06 1.0000E-06 8.3666E-05 2.0000E+02 > 1 18 Helmholtz VELZ F: 1.9136E-06 1.0000E-06 8.3666E-05 2.0000E+02 > 1 19 Helmholtz VELZ F: 1.5656E-06 1.0000E-06 8.3666E-05 2.0000E+02 > 1 20 Helmholtz VELZ F: 1.2877E-06 1.0000E-06 8.3666E-05 2.0000E+02 > 1 21 Helmholtz VELZ F: 1.0656E-06 1.0000E-06 8.3666E-05 2.0000E+02 > 1 22 Helmholtz VELZ F: 8.8191E-07 1.0000E-06 8.3666E-05 2.0000E+02 > 1 Hmholtz VELZ: 21 8.8191E-07 8.7446E-05 1.0000E-06 > L1/L2 DIV(V) : 2.0122E-21 5.8478E-05 > L1/L2 QTL : 0.0000E+00 0.0000E+00 > L1/L2 DIV(V)-QTL: 2.0122E-21 5.8478E-05 > 1 5.0000E-03 2.8596E+00 Fluid done > filt amp .0000 .0000 .0000 .0000 .0000 .0000 .0000 .0000 .0000 .0000 .0000 .0500 > filt trn 1.0000 1.0000 1.0000 1.0000 1.0000 1.0000 1.0000 1.0000 1.0000 1.0000 1.0000 .9500 > 1 5.0000E-03 -1.3839E-88 1.0000E+00 -3.9134E-06 3.9717E-06 uz_t_mx > Reading checkpoint data > 0 1 OPEN: G1_640.f00005 > byte swap: F 6.543210030 -0.2931277218E+36 > 12288 1 OPEN: G1_643.f00005 > 4096 1 OPEN: G1_641.f00005 > 8192 1 OPEN: G1_642.f00005 > > 1 2.2370E+02 done :: Read checkpoint data > avg data-throughput = -80.6MBps > io-nodes = 4 > > 0 1 OPEN: .fld > .fld > byte_read() :: fopen failure2! > > > Parameter 65 in the rea file is set to 4. Could it be that the initc is not correctly set? > > Thanks a lot, Joerg. > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Mon Jun 3 07:05:33 2013 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 3 Jun 2013 07:05:33 -0500 (CDT) Subject: [Nek5000-users] Problem with multiple file inut In-Reply-To: Message-ID: If I am not mistaken p66 and p67 are reset to be equal to 6 later in the code for .f/default format. The printed filename though has the empty base and extension .fld as if p67 is 4... Aleks ----- Original Message ----- From: nek5000-users at lists.mcs.anl.gov To: nek5000-users at lists.mcs.anl.gov Sent: Monday, June 3, 2013 7:00:15 AM Subject: Re: [Nek5000-users] Problem with multiple file inut Hi Aleks, p66 and p67 is set to 0.000E+00 Thanks Am 03.06.2013 um 13:52 schrieb nek5000-users at lists.mcs.anl.gov: > Hi Joerg, > > Most likely -- for some reason, the reading routines get a filename ".fld": > > 0 1 OPEN: .fld > .fld > > so you might also want to check a value of parameter(67) > > Best. > Aleks > > ----- Original Message ----- > From: nek5000-users at lists.mcs.anl.gov > To: nek5000-users at lists.mcs.anl.gov > Sent: Monday, June 3, 2013 5:46:23 AM > Subject: [Nek5000-users] Problem with multiple file inut > > Hi Neks, > > we want to run a post processing job analyzing further things of our full production job. > For output in single file things work well with the following patch of code in the usr file of > the analysis program: > > IF (istep.eq.1) THEN > > do k=1,xx > WRITE(fldfle,'("G1_640.f",I5.5)')k > initc(1) = trim(fldfle) > call restart(1) > > ?? do your analysis??.. > > enddo > > ENDIF > > It does the analysis for xx snapshots G1_640.f00001 to G1_640.f000xx that we generated > before. > > Bigger jobs requires multiple file outputs, e.g. here each snapshot goes into 4 separate files > G1_640.f0000x to G1_643.f0000x > > I thought that the corresponding extension should do it: > > > IF (istep.eq.1) THEN > > do k=1,xx > k1=4+k > WRITE(fldfle,'("G1_64?.f",I5.5)')k1 > initc(1) = trim(fldfle) > call restart(4) > > ?? do your analysis??.. > > enddo > > ENDIF > > > the patch of log file (see below) indicates that the program reads G1_640.f00005 to G1_643.f00005 correctly and > gets stuck afterwards when trying to read the four files G1_64*.f00006: > > > > New CG1-tolerance (RINIT*epsm) = 0.874462285180112059E-17 0.607013350432080170E-25 > 1 1 Helmholtz VELZ F: 8.7446E-05 1.0000E-06 8.3666E-05 2.0000E+02 > 1 2 Helmholtz VELZ F: 4.5200E-05 1.0000E-06 8.3666E-05 2.0000E+02 > 1 3 Helmholtz VELZ F: 3.1000E-05 1.0000E-06 8.3666E-05 2.0000E+02 > 1 4 Helmholtz VELZ F: 2.4871E-05 1.0000E-06 8.3666E-05 2.0000E+02 > 1 5 Helmholtz VELZ F: 2.0362E-05 1.0000E-06 8.3666E-05 2.0000E+02 > 1 6 Helmholtz VELZ F: 1.7312E-05 1.0000E-06 8.3666E-05 2.0000E+02 > 1 7 Helmholtz VELZ F: 1.4629E-05 1.0000E-06 8.3666E-05 2.0000E+02 > 1 8 Helmholtz VELZ F: 1.2836E-05 1.0000E-06 8.3666E-05 2.0000E+02 > 1 9 Helmholtz VELZ F: 1.1274E-05 1.0000E-06 8.3666E-05 2.0000E+02 > 1 10 Helmholtz VELZ F: 9.7394E-06 1.0000E-06 8.3666E-05 2.0000E+02 > 1 11 Helmholtz VELZ F: 8.3244E-06 1.0000E-06 8.3666E-05 2.0000E+02 > 1 12 Helmholtz VELZ F: 6.8927E-06 1.0000E-06 8.3666E-05 2.0000E+02 > 1 13 Helmholtz VELZ F: 5.5410E-06 1.0000E-06 8.3666E-05 2.0000E+02 > 1 14 Helmholtz VELZ F: 4.4505E-06 1.0000E-06 8.3666E-05 2.0000E+02 > 1 15 Helmholtz VELZ F: 3.5729E-06 1.0000E-06 8.3666E-05 2.0000E+02 > 1 16 Helmholtz VELZ F: 2.8812E-06 1.0000E-06 8.3666E-05 2.0000E+02 > 1 17 Helmholtz VELZ F: 2.3406E-06 1.0000E-06 8.3666E-05 2.0000E+02 > 1 18 Helmholtz VELZ F: 1.9136E-06 1.0000E-06 8.3666E-05 2.0000E+02 > 1 19 Helmholtz VELZ F: 1.5656E-06 1.0000E-06 8.3666E-05 2.0000E+02 > 1 20 Helmholtz VELZ F: 1.2877E-06 1.0000E-06 8.3666E-05 2.0000E+02 > 1 21 Helmholtz VELZ F: 1.0656E-06 1.0000E-06 8.3666E-05 2.0000E+02 > 1 22 Helmholtz VELZ F: 8.8191E-07 1.0000E-06 8.3666E-05 2.0000E+02 > 1 Hmholtz VELZ: 21 8.8191E-07 8.7446E-05 1.0000E-06 > L1/L2 DIV(V) : 2.0122E-21 5.8478E-05 > L1/L2 QTL : 0.0000E+00 0.0000E+00 > L1/L2 DIV(V)-QTL: 2.0122E-21 5.8478E-05 > 1 5.0000E-03 2.8596E+00 Fluid done > filt amp .0000 .0000 .0000 .0000 .0000 .0000 .0000 .0000 .0000 .0000 .0000 .0500 > filt trn 1.0000 1.0000 1.0000 1.0000 1.0000 1.0000 1.0000 1.0000 1.0000 1.0000 1.0000 .9500 > 1 5.0000E-03 -1.3839E-88 1.0000E+00 -3.9134E-06 3.9717E-06 uz_t_mx > Reading checkpoint data > 0 1 OPEN: G1_640.f00005 > byte swap: F 6.543210030 -0.2931277218E+36 > 12288 1 OPEN: G1_643.f00005 > 4096 1 OPEN: G1_641.f00005 > 8192 1 OPEN: G1_642.f00005 > > 1 2.2370E+02 done :: Read checkpoint data > avg data-throughput = -80.6MBps > io-nodes = 4 > > 0 1 OPEN: .fld > .fld > byte_read() :: fopen failure2! > > > Parameter 65 in the rea file is set to 4. Could it be that the initc is not correctly set? > > Thanks a lot, Joerg. > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Mon Jun 3 07:11:25 2013 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 3 Jun 2013 14:11:25 +0200 Subject: [Nek5000-users] Problem with multiple file inut In-Reply-To: References: Message-ID: Aleks, what does this mean in my particular case. Which name should the files have and which value should I prescribe for p66 and p67. Thanks a lot, Joerg. Am 03.06.2013 um 14:05 schrieb nek5000-users at lists.mcs.anl.gov: > If I am not mistaken p66 and p67 are reset to be equal to 6 later in the code for .f/default format. > > The printed filename though has the empty base and extension .fld as if p67 is 4... > > Aleks > > > ----- Original Message ----- > From: nek5000-users at lists.mcs.anl.gov > To: nek5000-users at lists.mcs.anl.gov > Sent: Monday, June 3, 2013 7:00:15 AM > Subject: Re: [Nek5000-users] Problem with multiple file inut > > Hi Aleks, > > p66 and p67 is set to 0.000E+00 > > Thanks > > Am 03.06.2013 um 13:52 schrieb nek5000-users at lists.mcs.anl.gov: > >> Hi Joerg, >> >> Most likely -- for some reason, the reading routines get a filename ".fld": >> >> 0 1 OPEN: .fld >> .fld >> >> so you might also want to check a value of parameter(67) >> >> Best. >> Aleks >> >> ----- Original Message ----- >> From: nek5000-users at lists.mcs.anl.gov >> To: nek5000-users at lists.mcs.anl.gov >> Sent: Monday, June 3, 2013 5:46:23 AM >> Subject: [Nek5000-users] Problem with multiple file inut >> >> Hi Neks, >> >> we want to run a post processing job analyzing further things of our full production job. >> For output in single file things work well with the following patch of code in the usr file of >> the analysis program: >> >> IF (istep.eq.1) THEN >> >> do k=1,xx >> WRITE(fldfle,'("G1_640.f",I5.5)')k >> initc(1) = trim(fldfle) >> call restart(1) >> >> ?? do your analysis??.. >> >> enddo >> >> ENDIF >> >> It does the analysis for xx snapshots G1_640.f00001 to G1_640.f000xx that we generated >> before. >> >> Bigger jobs requires multiple file outputs, e.g. here each snapshot goes into 4 separate files >> G1_640.f0000x to G1_643.f0000x >> >> I thought that the corresponding extension should do it: >> >> >> IF (istep.eq.1) THEN >> >> do k=1,xx >> k1=4+k >> WRITE(fldfle,'("G1_64?.f",I5.5)')k1 >> initc(1) = trim(fldfle) >> call restart(4) >> >> ?? do your analysis??.. >> >> enddo >> >> ENDIF >> >> >> the patch of log file (see below) indicates that the program reads G1_640.f00005 to G1_643.f00005 correctly and >> gets stuck afterwards when trying to read the four files G1_64*.f00006: >> >> >> >> New CG1-tolerance (RINIT*epsm) = 0.874462285180112059E-17 0.607013350432080170E-25 >> 1 1 Helmholtz VELZ F: 8.7446E-05 1.0000E-06 8.3666E-05 2.0000E+02 >> 1 2 Helmholtz VELZ F: 4.5200E-05 1.0000E-06 8.3666E-05 2.0000E+02 >> 1 3 Helmholtz VELZ F: 3.1000E-05 1.0000E-06 8.3666E-05 2.0000E+02 >> 1 4 Helmholtz VELZ F: 2.4871E-05 1.0000E-06 8.3666E-05 2.0000E+02 >> 1 5 Helmholtz VELZ F: 2.0362E-05 1.0000E-06 8.3666E-05 2.0000E+02 >> 1 6 Helmholtz VELZ F: 1.7312E-05 1.0000E-06 8.3666E-05 2.0000E+02 >> 1 7 Helmholtz VELZ F: 1.4629E-05 1.0000E-06 8.3666E-05 2.0000E+02 >> 1 8 Helmholtz VELZ F: 1.2836E-05 1.0000E-06 8.3666E-05 2.0000E+02 >> 1 9 Helmholtz VELZ F: 1.1274E-05 1.0000E-06 8.3666E-05 2.0000E+02 >> 1 10 Helmholtz VELZ F: 9.7394E-06 1.0000E-06 8.3666E-05 2.0000E+02 >> 1 11 Helmholtz VELZ F: 8.3244E-06 1.0000E-06 8.3666E-05 2.0000E+02 >> 1 12 Helmholtz VELZ F: 6.8927E-06 1.0000E-06 8.3666E-05 2.0000E+02 >> 1 13 Helmholtz VELZ F: 5.5410E-06 1.0000E-06 8.3666E-05 2.0000E+02 >> 1 14 Helmholtz VELZ F: 4.4505E-06 1.0000E-06 8.3666E-05 2.0000E+02 >> 1 15 Helmholtz VELZ F: 3.5729E-06 1.0000E-06 8.3666E-05 2.0000E+02 >> 1 16 Helmholtz VELZ F: 2.8812E-06 1.0000E-06 8.3666E-05 2.0000E+02 >> 1 17 Helmholtz VELZ F: 2.3406E-06 1.0000E-06 8.3666E-05 2.0000E+02 >> 1 18 Helmholtz VELZ F: 1.9136E-06 1.0000E-06 8.3666E-05 2.0000E+02 >> 1 19 Helmholtz VELZ F: 1.5656E-06 1.0000E-06 8.3666E-05 2.0000E+02 >> 1 20 Helmholtz VELZ F: 1.2877E-06 1.0000E-06 8.3666E-05 2.0000E+02 >> 1 21 Helmholtz VELZ F: 1.0656E-06 1.0000E-06 8.3666E-05 2.0000E+02 >> 1 22 Helmholtz VELZ F: 8.8191E-07 1.0000E-06 8.3666E-05 2.0000E+02 >> 1 Hmholtz VELZ: 21 8.8191E-07 8.7446E-05 1.0000E-06 >> L1/L2 DIV(V) : 2.0122E-21 5.8478E-05 >> L1/L2 QTL : 0.0000E+00 0.0000E+00 >> L1/L2 DIV(V)-QTL: 2.0122E-21 5.8478E-05 >> 1 5.0000E-03 2.8596E+00 Fluid done >> filt amp .0000 .0000 .0000 .0000 .0000 .0000 .0000 .0000 .0000 .0000 .0000 .0500 >> filt trn 1.0000 1.0000 1.0000 1.0000 1.0000 1.0000 1.0000 1.0000 1.0000 1.0000 1.0000 .9500 >> 1 5.0000E-03 -1.3839E-88 1.0000E+00 -3.9134E-06 3.9717E-06 uz_t_mx >> Reading checkpoint data >> 0 1 OPEN: G1_640.f00005 >> byte swap: F 6.543210030 -0.2931277218E+36 >> 12288 1 OPEN: G1_643.f00005 >> 4096 1 OPEN: G1_641.f00005 >> 8192 1 OPEN: G1_642.f00005 >> >> 1 2.2370E+02 done :: Read checkpoint data >> avg data-throughput = -80.6MBps >> io-nodes = 4 >> >> 0 1 OPEN: .fld >> .fld >> byte_read() :: fopen failure2! >> >> >> Parameter 65 in the rea file is set to 4. Could it be that the initc is not correctly set? >> >> Thanks a lot, Joerg. >> >> _______________________________________________ >> Nek5000-users mailing list >> Nek5000-users at lists.mcs.anl.gov >> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >> _______________________________________________ >> Nek5000-users mailing list >> Nek5000-users at lists.mcs.anl.gov >> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Mon Jun 3 07:17:17 2013 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 3 Jun 2013 07:17:17 -0500 (CDT) Subject: [Nek5000-users] Problem with multiple file inut In-Reply-To: Message-ID: For the default/.f format you do not need to set p66 & 67 yourself but I would start with a printout of your p66 and p67 together with the filename you want to read. Aleks ----- Original Message ----- From: nek5000-users at lists.mcs.anl.gov To: nek5000-users at lists.mcs.anl.gov Sent: Monday, June 3, 2013 7:11:25 AM Subject: Re: [Nek5000-users] Problem with multiple file inut Aleks, what does this mean in my particular case. Which name should the files have and which value should I prescribe for p66 and p67. Thanks a lot, Joerg. Am 03.06.2013 um 14:05 schrieb nek5000-users at lists.mcs.anl.gov: > If I am not mistaken p66 and p67 are reset to be equal to 6 later in the code for .f/default format. > > The printed filename though has the empty base and extension .fld as if p67 is 4... > > Aleks > > > ----- Original Message ----- > From: nek5000-users at lists.mcs.anl.gov > To: nek5000-users at lists.mcs.anl.gov > Sent: Monday, June 3, 2013 7:00:15 AM > Subject: Re: [Nek5000-users] Problem with multiple file inut > > Hi Aleks, > > p66 and p67 is set to 0.000E+00 > > Thanks > > Am 03.06.2013 um 13:52 schrieb nek5000-users at lists.mcs.anl.gov: > >> Hi Joerg, >> >> Most likely -- for some reason, the reading routines get a filename ".fld": >> >> 0 1 OPEN: .fld >> .fld >> >> so you might also want to check a value of parameter(67) >> >> Best. >> Aleks >> >> ----- Original Message ----- >> From: nek5000-users at lists.mcs.anl.gov >> To: nek5000-users at lists.mcs.anl.gov >> Sent: Monday, June 3, 2013 5:46:23 AM >> Subject: [Nek5000-users] Problem with multiple file inut >> >> Hi Neks, >> >> we want to run a post processing job analyzing further things of our full production job. >> For output in single file things work well with the following patch of code in the usr file of >> the analysis program: >> >> IF (istep.eq.1) THEN >> >> do k=1,xx >> WRITE(fldfle,'("G1_640.f",I5.5)')k >> initc(1) = trim(fldfle) >> call restart(1) >> >> ?? do your analysis??.. >> >> enddo >> >> ENDIF >> >> It does the analysis for xx snapshots G1_640.f00001 to G1_640.f000xx that we generated >> before. >> >> Bigger jobs requires multiple file outputs, e.g. here each snapshot goes into 4 separate files >> G1_640.f0000x to G1_643.f0000x >> >> I thought that the corresponding extension should do it: >> >> >> IF (istep.eq.1) THEN >> >> do k=1,xx >> k1=4+k >> WRITE(fldfle,'("G1_64?.f",I5.5)')k1 >> initc(1) = trim(fldfle) >> call restart(4) >> >> ?? do your analysis??.. >> >> enddo >> >> ENDIF >> >> >> the patch of log file (see below) indicates that the program reads G1_640.f00005 to G1_643.f00005 correctly and >> gets stuck afterwards when trying to read the four files G1_64*.f00006: >> >> >> >> New CG1-tolerance (RINIT*epsm) = 0.874462285180112059E-17 0.607013350432080170E-25 >> 1 1 Helmholtz VELZ F: 8.7446E-05 1.0000E-06 8.3666E-05 2.0000E+02 >> 1 2 Helmholtz VELZ F: 4.5200E-05 1.0000E-06 8.3666E-05 2.0000E+02 >> 1 3 Helmholtz VELZ F: 3.1000E-05 1.0000E-06 8.3666E-05 2.0000E+02 >> 1 4 Helmholtz VELZ F: 2.4871E-05 1.0000E-06 8.3666E-05 2.0000E+02 >> 1 5 Helmholtz VELZ F: 2.0362E-05 1.0000E-06 8.3666E-05 2.0000E+02 >> 1 6 Helmholtz VELZ F: 1.7312E-05 1.0000E-06 8.3666E-05 2.0000E+02 >> 1 7 Helmholtz VELZ F: 1.4629E-05 1.0000E-06 8.3666E-05 2.0000E+02 >> 1 8 Helmholtz VELZ F: 1.2836E-05 1.0000E-06 8.3666E-05 2.0000E+02 >> 1 9 Helmholtz VELZ F: 1.1274E-05 1.0000E-06 8.3666E-05 2.0000E+02 >> 1 10 Helmholtz VELZ F: 9.7394E-06 1.0000E-06 8.3666E-05 2.0000E+02 >> 1 11 Helmholtz VELZ F: 8.3244E-06 1.0000E-06 8.3666E-05 2.0000E+02 >> 1 12 Helmholtz VELZ F: 6.8927E-06 1.0000E-06 8.3666E-05 2.0000E+02 >> 1 13 Helmholtz VELZ F: 5.5410E-06 1.0000E-06 8.3666E-05 2.0000E+02 >> 1 14 Helmholtz VELZ F: 4.4505E-06 1.0000E-06 8.3666E-05 2.0000E+02 >> 1 15 Helmholtz VELZ F: 3.5729E-06 1.0000E-06 8.3666E-05 2.0000E+02 >> 1 16 Helmholtz VELZ F: 2.8812E-06 1.0000E-06 8.3666E-05 2.0000E+02 >> 1 17 Helmholtz VELZ F: 2.3406E-06 1.0000E-06 8.3666E-05 2.0000E+02 >> 1 18 Helmholtz VELZ F: 1.9136E-06 1.0000E-06 8.3666E-05 2.0000E+02 >> 1 19 Helmholtz VELZ F: 1.5656E-06 1.0000E-06 8.3666E-05 2.0000E+02 >> 1 20 Helmholtz VELZ F: 1.2877E-06 1.0000E-06 8.3666E-05 2.0000E+02 >> 1 21 Helmholtz VELZ F: 1.0656E-06 1.0000E-06 8.3666E-05 2.0000E+02 >> 1 22 Helmholtz VELZ F: 8.8191E-07 1.0000E-06 8.3666E-05 2.0000E+02 >> 1 Hmholtz VELZ: 21 8.8191E-07 8.7446E-05 1.0000E-06 >> L1/L2 DIV(V) : 2.0122E-21 5.8478E-05 >> L1/L2 QTL : 0.0000E+00 0.0000E+00 >> L1/L2 DIV(V)-QTL: 2.0122E-21 5.8478E-05 >> 1 5.0000E-03 2.8596E+00 Fluid done >> filt amp .0000 .0000 .0000 .0000 .0000 .0000 .0000 .0000 .0000 .0000 .0000 .0500 >> filt trn 1.0000 1.0000 1.0000 1.0000 1.0000 1.0000 1.0000 1.0000 1.0000 1.0000 1.0000 .9500 >> 1 5.0000E-03 -1.3839E-88 1.0000E+00 -3.9134E-06 3.9717E-06 uz_t_mx >> Reading checkpoint data >> 0 1 OPEN: G1_640.f00005 >> byte swap: F 6.543210030 -0.2931277218E+36 >> 12288 1 OPEN: G1_643.f00005 >> 4096 1 OPEN: G1_641.f00005 >> 8192 1 OPEN: G1_642.f00005 >> >> 1 2.2370E+02 done :: Read checkpoint data >> avg data-throughput = -80.6MBps >> io-nodes = 4 >> >> 0 1 OPEN: .fld >> .fld >> byte_read() :: fopen failure2! >> >> >> Parameter 65 in the rea file is set to 4. Could it be that the initc is not correctly set? >> >> Thanks a lot, Joerg. >> >> _______________________________________________ >> Nek5000-users mailing list >> Nek5000-users at lists.mcs.anl.gov >> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >> _______________________________________________ >> Nek5000-users mailing list >> Nek5000-users at lists.mcs.anl.gov >> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Mon Jun 3 07:23:22 2013 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 3 Jun 2013 14:23:22 +0200 Subject: [Nek5000-users] Problem with multiple file inut In-Reply-To: References: Message-ID: I am sorry, I don't understand your reply: my rea file tells me that p66 and p67 specify binary or ascii. We use always binary. How does the particular name file enter? Am 03.06.2013 um 14:17 schrieb nek5000-users at lists.mcs.anl.gov: > For the default/.f format you do not need to set p66 & 67 yourself but I would start with a printout of your p66 and p67 together with the filename you want to read. > > Aleks > > ----- Original Message ----- > From: nek5000-users at lists.mcs.anl.gov > To: nek5000-users at lists.mcs.anl.gov > Sent: Monday, June 3, 2013 7:11:25 AM > Subject: Re: [Nek5000-users] Problem with multiple file inut > > Aleks, what does this mean in my particular case. > > Which name should the files have and which value should I prescribe for p66 and p67. > > Thanks a lot, Joerg. > > > Am 03.06.2013 um 14:05 schrieb nek5000-users at lists.mcs.anl.gov: > >> If I am not mistaken p66 and p67 are reset to be equal to 6 later in the code for .f/default format. >> >> The printed filename though has the empty base and extension .fld as if p67 is 4... >> >> Aleks >> >> >> ----- Original Message ----- >> From: nek5000-users at lists.mcs.anl.gov >> To: nek5000-users at lists.mcs.anl.gov >> Sent: Monday, June 3, 2013 7:00:15 AM >> Subject: Re: [Nek5000-users] Problem with multiple file inut >> >> Hi Aleks, >> >> p66 and p67 is set to 0.000E+00 >> >> Thanks >> >> Am 03.06.2013 um 13:52 schrieb nek5000-users at lists.mcs.anl.gov: >> >>> Hi Joerg, >>> >>> Most likely -- for some reason, the reading routines get a filename ".fld": >>> >>> 0 1 OPEN: .fld >>> .fld >>> >>> so you might also want to check a value of parameter(67) >>> >>> Best. >>> Aleks >>> >>> ----- Original Message ----- >>> From: nek5000-users at lists.mcs.anl.gov >>> To: nek5000-users at lists.mcs.anl.gov >>> Sent: Monday, June 3, 2013 5:46:23 AM >>> Subject: [Nek5000-users] Problem with multiple file inut >>> >>> Hi Neks, >>> >>> we want to run a post processing job analyzing further things of our full production job. >>> For output in single file things work well with the following patch of code in the usr file of >>> the analysis program: >>> >>> IF (istep.eq.1) THEN >>> >>> do k=1,xx >>> WRITE(fldfle,'("G1_640.f",I5.5)')k >>> initc(1) = trim(fldfle) >>> call restart(1) >>> >>> ?? do your analysis??.. >>> >>> enddo >>> >>> ENDIF >>> >>> It does the analysis for xx snapshots G1_640.f00001 to G1_640.f000xx that we generated >>> before. >>> >>> Bigger jobs requires multiple file outputs, e.g. here each snapshot goes into 4 separate files >>> G1_640.f0000x to G1_643.f0000x >>> >>> I thought that the corresponding extension should do it: >>> >>> >>> IF (istep.eq.1) THEN >>> >>> do k=1,xx >>> k1=4+k >>> WRITE(fldfle,'("G1_64?.f",I5.5)')k1 >>> initc(1) = trim(fldfle) >>> call restart(4) >>> >>> ?? do your analysis??.. >>> >>> enddo >>> >>> ENDIF >>> >>> >>> the patch of log file (see below) indicates that the program reads G1_640.f00005 to G1_643.f00005 correctly and >>> gets stuck afterwards when trying to read the four files G1_64*.f00006: >>> >>> >>> >>> New CG1-tolerance (RINIT*epsm) = 0.874462285180112059E-17 0.607013350432080170E-25 >>> 1 1 Helmholtz VELZ F: 8.7446E-05 1.0000E-06 8.3666E-05 2.0000E+02 >>> 1 2 Helmholtz VELZ F: 4.5200E-05 1.0000E-06 8.3666E-05 2.0000E+02 >>> 1 3 Helmholtz VELZ F: 3.1000E-05 1.0000E-06 8.3666E-05 2.0000E+02 >>> 1 4 Helmholtz VELZ F: 2.4871E-05 1.0000E-06 8.3666E-05 2.0000E+02 >>> 1 5 Helmholtz VELZ F: 2.0362E-05 1.0000E-06 8.3666E-05 2.0000E+02 >>> 1 6 Helmholtz VELZ F: 1.7312E-05 1.0000E-06 8.3666E-05 2.0000E+02 >>> 1 7 Helmholtz VELZ F: 1.4629E-05 1.0000E-06 8.3666E-05 2.0000E+02 >>> 1 8 Helmholtz VELZ F: 1.2836E-05 1.0000E-06 8.3666E-05 2.0000E+02 >>> 1 9 Helmholtz VELZ F: 1.1274E-05 1.0000E-06 8.3666E-05 2.0000E+02 >>> 1 10 Helmholtz VELZ F: 9.7394E-06 1.0000E-06 8.3666E-05 2.0000E+02 >>> 1 11 Helmholtz VELZ F: 8.3244E-06 1.0000E-06 8.3666E-05 2.0000E+02 >>> 1 12 Helmholtz VELZ F: 6.8927E-06 1.0000E-06 8.3666E-05 2.0000E+02 >>> 1 13 Helmholtz VELZ F: 5.5410E-06 1.0000E-06 8.3666E-05 2.0000E+02 >>> 1 14 Helmholtz VELZ F: 4.4505E-06 1.0000E-06 8.3666E-05 2.0000E+02 >>> 1 15 Helmholtz VELZ F: 3.5729E-06 1.0000E-06 8.3666E-05 2.0000E+02 >>> 1 16 Helmholtz VELZ F: 2.8812E-06 1.0000E-06 8.3666E-05 2.0000E+02 >>> 1 17 Helmholtz VELZ F: 2.3406E-06 1.0000E-06 8.3666E-05 2.0000E+02 >>> 1 18 Helmholtz VELZ F: 1.9136E-06 1.0000E-06 8.3666E-05 2.0000E+02 >>> 1 19 Helmholtz VELZ F: 1.5656E-06 1.0000E-06 8.3666E-05 2.0000E+02 >>> 1 20 Helmholtz VELZ F: 1.2877E-06 1.0000E-06 8.3666E-05 2.0000E+02 >>> 1 21 Helmholtz VELZ F: 1.0656E-06 1.0000E-06 8.3666E-05 2.0000E+02 >>> 1 22 Helmholtz VELZ F: 8.8191E-07 1.0000E-06 8.3666E-05 2.0000E+02 >>> 1 Hmholtz VELZ: 21 8.8191E-07 8.7446E-05 1.0000E-06 >>> L1/L2 DIV(V) : 2.0122E-21 5.8478E-05 >>> L1/L2 QTL : 0.0000E+00 0.0000E+00 >>> L1/L2 DIV(V)-QTL: 2.0122E-21 5.8478E-05 >>> 1 5.0000E-03 2.8596E+00 Fluid done >>> filt amp .0000 .0000 .0000 .0000 .0000 .0000 .0000 .0000 .0000 .0000 .0000 .0500 >>> filt trn 1.0000 1.0000 1.0000 1.0000 1.0000 1.0000 1.0000 1.0000 1.0000 1.0000 1.0000 .9500 >>> 1 5.0000E-03 -1.3839E-88 1.0000E+00 -3.9134E-06 3.9717E-06 uz_t_mx >>> Reading checkpoint data >>> 0 1 OPEN: G1_640.f00005 >>> byte swap: F 6.543210030 -0.2931277218E+36 >>> 12288 1 OPEN: G1_643.f00005 >>> 4096 1 OPEN: G1_641.f00005 >>> 8192 1 OPEN: G1_642.f00005 >>> >>> 1 2.2370E+02 done :: Read checkpoint data >>> avg data-throughput = -80.6MBps >>> io-nodes = 4 >>> >>> 0 1 OPEN: .fld >>> .fld >>> byte_read() :: fopen failure2! >>> >>> >>> Parameter 65 in the rea file is set to 4. Could it be that the initc is not correctly set? >>> >>> Thanks a lot, Joerg. >>> >>> _______________________________________________ >>> Nek5000-users mailing list >>> Nek5000-users at lists.mcs.anl.gov >>> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >>> _______________________________________________ >>> Nek5000-users mailing list >>> Nek5000-users at lists.mcs.anl.gov >>> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >> >> _______________________________________________ >> Nek5000-users mailing list >> Nek5000-users at lists.mcs.anl.gov >> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >> _______________________________________________ >> Nek5000-users mailing list >> Nek5000-users at lists.mcs.anl.gov >> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Mon Jun 3 07:41:38 2013 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 3 Jun 2013 07:41:38 -0500 (CDT) Subject: [Nek5000-users] Problem with multiple file inut In-Reply-To: Message-ID: >From the lines of your logfile, I see the first filename G1_640.f00005 read correctly Reading checkpoint data 0 1 OPEN: G1_640.f00005 while the next filename you are trying to read shows up as 0 1 OPEN: .fld which means the second file Nek is trying to read is ".fld" for some reason -- I would suggest checking how you set the filename for the second file. Aleks ----- Original Message ----- From: nek5000-users at lists.mcs.anl.gov To: nek5000-users at lists.mcs.anl.gov Sent: Monday, June 3, 2013 7:23:22 AM Subject: Re: [Nek5000-users] Problem with multiple file inut I am sorry, I don't understand your reply: my rea file tells me that p66 and p67 specify binary or ascii. We use always binary. How does the particular name file enter? Am 03.06.2013 um 14:17 schrieb nek5000-users at lists.mcs.anl.gov: > For the default/.f format you do not need to set p66 & 67 yourself but I would start with a printout of your p66 and p67 together with the filename you want to read. > > Aleks > > ----- Original Message ----- > From: nek5000-users at lists.mcs.anl.gov > To: nek5000-users at lists.mcs.anl.gov > Sent: Monday, June 3, 2013 7:11:25 AM > Subject: Re: [Nek5000-users] Problem with multiple file inut > > Aleks, what does this mean in my particular case. > > Which name should the files have and which value should I prescribe for p66 and p67. > > Thanks a lot, Joerg. > > > Am 03.06.2013 um 14:05 schrieb nek5000-users at lists.mcs.anl.gov: > >> If I am not mistaken p66 and p67 are reset to be equal to 6 later in the code for .f/default format. >> >> The printed filename though has the empty base and extension .fld as if p67 is 4... >> >> Aleks >> >> >> ----- Original Message ----- >> From: nek5000-users at lists.mcs.anl.gov >> To: nek5000-users at lists.mcs.anl.gov >> Sent: Monday, June 3, 2013 7:00:15 AM >> Subject: Re: [Nek5000-users] Problem with multiple file inut >> >> Hi Aleks, >> >> p66 and p67 is set to 0.000E+00 >> >> Thanks >> >> Am 03.06.2013 um 13:52 schrieb nek5000-users at lists.mcs.anl.gov: >> >>> Hi Joerg, >>> >>> Most likely -- for some reason, the reading routines get a filename ".fld": >>> >>> 0 1 OPEN: .fld >>> .fld >>> >>> so you might also want to check a value of parameter(67) >>> >>> Best. >>> Aleks >>> >>> ----- Original Message ----- >>> From: nek5000-users at lists.mcs.anl.gov >>> To: nek5000-users at lists.mcs.anl.gov >>> Sent: Monday, June 3, 2013 5:46:23 AM >>> Subject: [Nek5000-users] Problem with multiple file inut >>> >>> Hi Neks, >>> >>> we want to run a post processing job analyzing further things of our full production job. >>> For output in single file things work well with the following patch of code in the usr file of >>> the analysis program: >>> >>> IF (istep.eq.1) THEN >>> >>> do k=1,xx >>> WRITE(fldfle,'("G1_640.f",I5.5)')k >>> initc(1) = trim(fldfle) >>> call restart(1) >>> >>> ?? do your analysis??.. >>> >>> enddo >>> >>> ENDIF >>> >>> It does the analysis for xx snapshots G1_640.f00001 to G1_640.f000xx that we generated >>> before. >>> >>> Bigger jobs requires multiple file outputs, e.g. here each snapshot goes into 4 separate files >>> G1_640.f0000x to G1_643.f0000x >>> >>> I thought that the corresponding extension should do it: >>> >>> >>> IF (istep.eq.1) THEN >>> >>> do k=1,xx >>> k1=4+k >>> WRITE(fldfle,'("G1_64?.f",I5.5)')k1 >>> initc(1) = trim(fldfle) >>> call restart(4) >>> >>> ?? do your analysis??.. >>> >>> enddo >>> >>> ENDIF >>> >>> >>> the patch of log file (see below) indicates that the program reads G1_640.f00005 to G1_643.f00005 correctly and >>> gets stuck afterwards when trying to read the four files G1_64*.f00006: >>> >>> >>> >>> New CG1-tolerance (RINIT*epsm) = 0.874462285180112059E-17 0.607013350432080170E-25 >>> 1 1 Helmholtz VELZ F: 8.7446E-05 1.0000E-06 8.3666E-05 2.0000E+02 >>> 1 2 Helmholtz VELZ F: 4.5200E-05 1.0000E-06 8.3666E-05 2.0000E+02 >>> 1 3 Helmholtz VELZ F: 3.1000E-05 1.0000E-06 8.3666E-05 2.0000E+02 >>> 1 4 Helmholtz VELZ F: 2.4871E-05 1.0000E-06 8.3666E-05 2.0000E+02 >>> 1 5 Helmholtz VELZ F: 2.0362E-05 1.0000E-06 8.3666E-05 2.0000E+02 >>> 1 6 Helmholtz VELZ F: 1.7312E-05 1.0000E-06 8.3666E-05 2.0000E+02 >>> 1 7 Helmholtz VELZ F: 1.4629E-05 1.0000E-06 8.3666E-05 2.0000E+02 >>> 1 8 Helmholtz VELZ F: 1.2836E-05 1.0000E-06 8.3666E-05 2.0000E+02 >>> 1 9 Helmholtz VELZ F: 1.1274E-05 1.0000E-06 8.3666E-05 2.0000E+02 >>> 1 10 Helmholtz VELZ F: 9.7394E-06 1.0000E-06 8.3666E-05 2.0000E+02 >>> 1 11 Helmholtz VELZ F: 8.3244E-06 1.0000E-06 8.3666E-05 2.0000E+02 >>> 1 12 Helmholtz VELZ F: 6.8927E-06 1.0000E-06 8.3666E-05 2.0000E+02 >>> 1 13 Helmholtz VELZ F: 5.5410E-06 1.0000E-06 8.3666E-05 2.0000E+02 >>> 1 14 Helmholtz VELZ F: 4.4505E-06 1.0000E-06 8.3666E-05 2.0000E+02 >>> 1 15 Helmholtz VELZ F: 3.5729E-06 1.0000E-06 8.3666E-05 2.0000E+02 >>> 1 16 Helmholtz VELZ F: 2.8812E-06 1.0000E-06 8.3666E-05 2.0000E+02 >>> 1 17 Helmholtz VELZ F: 2.3406E-06 1.0000E-06 8.3666E-05 2.0000E+02 >>> 1 18 Helmholtz VELZ F: 1.9136E-06 1.0000E-06 8.3666E-05 2.0000E+02 >>> 1 19 Helmholtz VELZ F: 1.5656E-06 1.0000E-06 8.3666E-05 2.0000E+02 >>> 1 20 Helmholtz VELZ F: 1.2877E-06 1.0000E-06 8.3666E-05 2.0000E+02 >>> 1 21 Helmholtz VELZ F: 1.0656E-06 1.0000E-06 8.3666E-05 2.0000E+02 >>> 1 22 Helmholtz VELZ F: 8.8191E-07 1.0000E-06 8.3666E-05 2.0000E+02 >>> 1 Hmholtz VELZ: 21 8.8191E-07 8.7446E-05 1.0000E-06 >>> L1/L2 DIV(V) : 2.0122E-21 5.8478E-05 >>> L1/L2 QTL : 0.0000E+00 0.0000E+00 >>> L1/L2 DIV(V)-QTL: 2.0122E-21 5.8478E-05 >>> 1 5.0000E-03 2.8596E+00 Fluid done >>> filt amp .0000 .0000 .0000 .0000 .0000 .0000 .0000 .0000 .0000 .0000 .0000 .0500 >>> filt trn 1.0000 1.0000 1.0000 1.0000 1.0000 1.0000 1.0000 1.0000 1.0000 1.0000 1.0000 .9500 >>> 1 5.0000E-03 -1.3839E-88 1.0000E+00 -3.9134E-06 3.9717E-06 uz_t_mx >>> Reading checkpoint data >>> 0 1 OPEN: G1_640.f00005 >>> byte swap: F 6.543210030 -0.2931277218E+36 >>> 12288 1 OPEN: G1_643.f00005 >>> 4096 1 OPEN: G1_641.f00005 >>> 8192 1 OPEN: G1_642.f00005 >>> >>> 1 2.2370E+02 done :: Read checkpoint data >>> avg data-throughput = -80.6MBps >>> io-nodes = 4 >>> >>> 0 1 OPEN: .fld >>> .fld >>> byte_read() :: fopen failure2! >>> >>> >>> Parameter 65 in the rea file is set to 4. Could it be that the initc is not correctly set? >>> >>> Thanks a lot, Joerg. >>> >>> _______________________________________________ >>> Nek5000-users mailing list >>> Nek5000-users at lists.mcs.anl.gov >>> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >>> _______________________________________________ >>> Nek5000-users mailing list >>> Nek5000-users at lists.mcs.anl.gov >>> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >> >> _______________________________________________ >> Nek5000-users mailing list >> Nek5000-users at lists.mcs.anl.gov >> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >> _______________________________________________ >> Nek5000-users mailing list >> Nek5000-users at lists.mcs.anl.gov >> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Mon Jun 3 08:08:56 2013 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 3 Jun 2013 15:08:56 +0200 Subject: [Nek5000-users] Problem with multiple file inut In-Reply-To: References: Message-ID: I would like to read in G1_640.f00006 as the next file. My question is therefore: where is it exactly encoded that nek wants to read .fld? As I said, for single output files it works without trouble. Here, I have to split into multiple files since they become big. Is "call restart(4)" correct? Thanks a lot. Am 03.06.2013 um 14:41 schrieb nek5000-users at lists.mcs.anl.gov: > From the lines of your logfile, I see the first filename G1_640.f00005 read correctly > > Reading checkpoint data > 0 1 OPEN: G1_640.f00005 > > while the next filename you are trying to read shows up as > > 0 1 OPEN: .fld > > which means the second file Nek is trying to read is ".fld" for some reason -- I would suggest checking how you set the filename for the second file. > > Aleks > > ----- Original Message ----- > From: nek5000-users at lists.mcs.anl.gov > To: nek5000-users at lists.mcs.anl.gov > Sent: Monday, June 3, 2013 7:23:22 AM > Subject: Re: [Nek5000-users] Problem with multiple file inut > > I am sorry, I don't understand your reply: > > my rea file tells me that p66 and p67 specify binary or ascii. We use always binary. > How does the particular name file enter? > > > > Am 03.06.2013 um 14:17 schrieb nek5000-users at lists.mcs.anl.gov: > >> For the default/.f format you do not need to set p66 & 67 yourself but I would start with a printout of your p66 and p67 together with the filename you want to read. >> >> Aleks >> >> ----- Original Message ----- >> From: nek5000-users at lists.mcs.anl.gov >> To: nek5000-users at lists.mcs.anl.gov >> Sent: Monday, June 3, 2013 7:11:25 AM >> Subject: Re: [Nek5000-users] Problem with multiple file inut >> >> Aleks, what does this mean in my particular case. >> >> Which name should the files have and which value should I prescribe for p66 and p67. >> >> Thanks a lot, Joerg. >> >> >> Am 03.06.2013 um 14:05 schrieb nek5000-users at lists.mcs.anl.gov: >> >>> If I am not mistaken p66 and p67 are reset to be equal to 6 later in the code for .f/default format. >>> >>> The printed filename though has the empty base and extension .fld as if p67 is 4... >>> >>> Aleks >>> >>> >>> ----- Original Message ----- >>> From: nek5000-users at lists.mcs.anl.gov >>> To: nek5000-users at lists.mcs.anl.gov >>> Sent: Monday, June 3, 2013 7:00:15 AM >>> Subject: Re: [Nek5000-users] Problem with multiple file inut >>> >>> Hi Aleks, >>> >>> p66 and p67 is set to 0.000E+00 >>> >>> Thanks >>> >>> Am 03.06.2013 um 13:52 schrieb nek5000-users at lists.mcs.anl.gov: >>> >>>> Hi Joerg, >>>> >>>> Most likely -- for some reason, the reading routines get a filename ".fld": >>>> >>>> 0 1 OPEN: .fld >>>> .fld >>>> >>>> so you might also want to check a value of parameter(67) >>>> >>>> Best. >>>> Aleks >>>> >>>> ----- Original Message ----- >>>> From: nek5000-users at lists.mcs.anl.gov >>>> To: nek5000-users at lists.mcs.anl.gov >>>> Sent: Monday, June 3, 2013 5:46:23 AM >>>> Subject: [Nek5000-users] Problem with multiple file inut >>>> >>>> Hi Neks, >>>> >>>> we want to run a post processing job analyzing further things of our full production job. >>>> For output in single file things work well with the following patch of code in the usr file of >>>> the analysis program: >>>> >>>> IF (istep.eq.1) THEN >>>> >>>> do k=1,xx >>>> WRITE(fldfle,'("G1_640.f",I5.5)')k >>>> initc(1) = trim(fldfle) >>>> call restart(1) >>>> >>>> ?? do your analysis??.. >>>> >>>> enddo >>>> >>>> ENDIF >>>> >>>> It does the analysis for xx snapshots G1_640.f00001 to G1_640.f000xx that we generated >>>> before. >>>> >>>> Bigger jobs requires multiple file outputs, e.g. here each snapshot goes into 4 separate files >>>> G1_640.f0000x to G1_643.f0000x >>>> >>>> I thought that the corresponding extension should do it: >>>> >>>> >>>> IF (istep.eq.1) THEN >>>> >>>> do k=1,xx >>>> k1=4+k >>>> WRITE(fldfle,'("G1_64?.f",I5.5)')k1 >>>> initc(1) = trim(fldfle) >>>> call restart(4) >>>> >>>> ?? do your analysis??.. >>>> >>>> enddo >>>> >>>> ENDIF >>>> >>>> >>>> the patch of log file (see below) indicates that the program reads G1_640.f00005 to G1_643.f00005 correctly and >>>> gets stuck afterwards when trying to read the four files G1_64*.f00006: >>>> >>>> >>>> >>>> New CG1-tolerance (RINIT*epsm) = 0.874462285180112059E-17 0.607013350432080170E-25 >>>> 1 1 Helmholtz VELZ F: 8.7446E-05 1.0000E-06 8.3666E-05 2.0000E+02 >>>> 1 2 Helmholtz VELZ F: 4.5200E-05 1.0000E-06 8.3666E-05 2.0000E+02 >>>> 1 3 Helmholtz VELZ F: 3.1000E-05 1.0000E-06 8.3666E-05 2.0000E+02 >>>> 1 4 Helmholtz VELZ F: 2.4871E-05 1.0000E-06 8.3666E-05 2.0000E+02 >>>> 1 5 Helmholtz VELZ F: 2.0362E-05 1.0000E-06 8.3666E-05 2.0000E+02 >>>> 1 6 Helmholtz VELZ F: 1.7312E-05 1.0000E-06 8.3666E-05 2.0000E+02 >>>> 1 7 Helmholtz VELZ F: 1.4629E-05 1.0000E-06 8.3666E-05 2.0000E+02 >>>> 1 8 Helmholtz VELZ F: 1.2836E-05 1.0000E-06 8.3666E-05 2.0000E+02 >>>> 1 9 Helmholtz VELZ F: 1.1274E-05 1.0000E-06 8.3666E-05 2.0000E+02 >>>> 1 10 Helmholtz VELZ F: 9.7394E-06 1.0000E-06 8.3666E-05 2.0000E+02 >>>> 1 11 Helmholtz VELZ F: 8.3244E-06 1.0000E-06 8.3666E-05 2.0000E+02 >>>> 1 12 Helmholtz VELZ F: 6.8927E-06 1.0000E-06 8.3666E-05 2.0000E+02 >>>> 1 13 Helmholtz VELZ F: 5.5410E-06 1.0000E-06 8.3666E-05 2.0000E+02 >>>> 1 14 Helmholtz VELZ F: 4.4505E-06 1.0000E-06 8.3666E-05 2.0000E+02 >>>> 1 15 Helmholtz VELZ F: 3.5729E-06 1.0000E-06 8.3666E-05 2.0000E+02 >>>> 1 16 Helmholtz VELZ F: 2.8812E-06 1.0000E-06 8.3666E-05 2.0000E+02 >>>> 1 17 Helmholtz VELZ F: 2.3406E-06 1.0000E-06 8.3666E-05 2.0000E+02 >>>> 1 18 Helmholtz VELZ F: 1.9136E-06 1.0000E-06 8.3666E-05 2.0000E+02 >>>> 1 19 Helmholtz VELZ F: 1.5656E-06 1.0000E-06 8.3666E-05 2.0000E+02 >>>> 1 20 Helmholtz VELZ F: 1.2877E-06 1.0000E-06 8.3666E-05 2.0000E+02 >>>> 1 21 Helmholtz VELZ F: 1.0656E-06 1.0000E-06 8.3666E-05 2.0000E+02 >>>> 1 22 Helmholtz VELZ F: 8.8191E-07 1.0000E-06 8.3666E-05 2.0000E+02 >>>> 1 Hmholtz VELZ: 21 8.8191E-07 8.7446E-05 1.0000E-06 >>>> L1/L2 DIV(V) : 2.0122E-21 5.8478E-05 >>>> L1/L2 QTL : 0.0000E+00 0.0000E+00 >>>> L1/L2 DIV(V)-QTL: 2.0122E-21 5.8478E-05 >>>> 1 5.0000E-03 2.8596E+00 Fluid done >>>> filt amp .0000 .0000 .0000 .0000 .0000 .0000 .0000 .0000 .0000 .0000 .0000 .0500 >>>> filt trn 1.0000 1.0000 1.0000 1.0000 1.0000 1.0000 1.0000 1.0000 1.0000 1.0000 1.0000 .9500 >>>> 1 5.0000E-03 -1.3839E-88 1.0000E+00 -3.9134E-06 3.9717E-06 uz_t_mx >>>> Reading checkpoint data >>>> 0 1 OPEN: G1_640.f00005 >>>> byte swap: F 6.543210030 -0.2931277218E+36 >>>> 12288 1 OPEN: G1_643.f00005 >>>> 4096 1 OPEN: G1_641.f00005 >>>> 8192 1 OPEN: G1_642.f00005 >>>> >>>> 1 2.2370E+02 done :: Read checkpoint data >>>> avg data-throughput = -80.6MBps >>>> io-nodes = 4 >>>> >>>> 0 1 OPEN: .fld >>>> .fld >>>> byte_read() :: fopen failure2! >>>> >>>> >>>> Parameter 65 in the rea file is set to 4. Could it be that the initc is not correctly set? >>>> >>>> Thanks a lot, Joerg. >>>> >>>> _______________________________________________ >>>> Nek5000-users mailing list >>>> Nek5000-users at lists.mcs.anl.gov >>>> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >>>> _______________________________________________ >>>> Nek5000-users mailing list >>>> Nek5000-users at lists.mcs.anl.gov >>>> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >>> >>> _______________________________________________ >>> Nek5000-users mailing list >>> Nek5000-users at lists.mcs.anl.gov >>> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >>> _______________________________________________ >>> Nek5000-users mailing list >>> Nek5000-users at lists.mcs.anl.gov >>> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >> >> _______________________________________________ >> Nek5000-users mailing list >> Nek5000-users at lists.mcs.anl.gov >> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >> _______________________________________________ >> Nek5000-users mailing list >> Nek5000-users at lists.mcs.anl.gov >> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Mon Jun 3 09:03:50 2013 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 3 Jun 2013 09:03:50 -0500 (CDT) Subject: [Nek5000-users] Problem with multiple file inut In-Reply-To: References: Message-ID: Hi Joerg, The f0000 file format is different than .fld, so you have the following options: a) .fld: Single file - no parallel i/o --- supports ascii or binary b) .f00000: Single or mulitiple files, parallel i/o, binary only. c) The input and output need not be the same, so you can convert from one file format to another. d) The default is to have the single-file f00000 format, assuming you have compiled with mpi-i/o (which is mandatory for that particular format). e) Otherwise, you get the multi-file f00000 format, where the number of files (and parallel i/o nodes) is based on the value of p65 in the .rea file. If p65=0 it defaults to a single file and no parallel i/o (unless you've compiled with mpi-i/o, per (d) above). It seems to me that you currently have the Case (e). Here, you have the option of also specifying a different directory for each output file---this is generally a _very_ good idea, otherwise you can end up with 6400 files in the same directory and the unix file system dies --- things like "ls" are often implemented with O(n^2) algorithms. If I were using Case (e) [ I personally prefer (d) ], I would do the following: e.1) Set p65= -64 [ 64 i/o nodes, 64 subdirectories; setting p65 < 0 indicates to use separate subdirectories. e.2) Set p66=6 [ though I think it defaults to this ] e.3) I would then create subdirectories A00, A01, A02, ... , A63 e.4) I use the attached "mkdirs.c" code, with the cmd line argument 64 (in this case): mkdirs A 64 to make these directories. e.5) Your files for output number k, blah00.f0000k, blah01.f0000k, etc., will be in directoies A01, A02, .... etc. f) To later restart with these files, you set p67=6 and in the "restart" line you put A??/blah??.f00007 say. Paul On Mon, 3 Jun 2013, nek5000-users at lists.mcs.anl.gov wrote: > I would like to read in G1_640.f00006 as the next file. > > My question is therefore: where is it exactly encoded that nek wants to read .fld? > As I said, for single output files it works without trouble. Here, I have to split into > multiple files since they become big. > > Is "call restart(4)" correct? > > Thanks a lot. > > Am 03.06.2013 um 14:41 schrieb nek5000-users at lists.mcs.anl.gov: > >> From the lines of your logfile, I see the first filename G1_640.f00005 read correctly >> >> Reading checkpoint data >> 0 1 OPEN: G1_640.f00005 >> >> while the next filename you are trying to read shows up as >> >> 0 1 OPEN: .fld >> >> which means the second file Nek is trying to read is ".fld" for some reason -- I would suggest checking how you set the filename for the second file. >> >> Aleks >> >> ----- Original Message ----- >> From: nek5000-users at lists.mcs.anl.gov >> To: nek5000-users at lists.mcs.anl.gov >> Sent: Monday, June 3, 2013 7:23:22 AM >> Subject: Re: [Nek5000-users] Problem with multiple file inut >> >> I am sorry, I don't understand your reply: >> >> my rea file tells me that p66 and p67 specify binary or ascii. We use always binary. >> How does the particular name file enter? >> >> >> >> Am 03.06.2013 um 14:17 schrieb nek5000-users at lists.mcs.anl.gov: >> >>> For the default/.f format you do not need to set p66 & 67 yourself but I would start with a printout of your p66 and p67 together with the filename you want to read. >>> >>> Aleks >>> >>> ----- Original Message ----- >>> From: nek5000-users at lists.mcs.anl.gov >>> To: nek5000-users at lists.mcs.anl.gov >>> Sent: Monday, June 3, 2013 7:11:25 AM >>> Subject: Re: [Nek5000-users] Problem with multiple file inut >>> >>> Aleks, what does this mean in my particular case. >>> >>> Which name should the files have and which value should I prescribe for p66 and p67. >>> >>> Thanks a lot, Joerg. >>> >>> >>> Am 03.06.2013 um 14:05 schrieb nek5000-users at lists.mcs.anl.gov: >>> >>>> If I am not mistaken p66 and p67 are reset to be equal to 6 later in the code for .f/default format. >>>> >>>> The printed filename though has the empty base and extension .fld as if p67 is 4... >>>> >>>> Aleks >>>> >>>> >>>> ----- Original Message ----- >>>> From: nek5000-users at lists.mcs.anl.gov >>>> To: nek5000-users at lists.mcs.anl.gov >>>> Sent: Monday, June 3, 2013 7:00:15 AM >>>> Subject: Re: [Nek5000-users] Problem with multiple file inut >>>> >>>> Hi Aleks, >>>> >>>> p66 and p67 is set to 0.000E+00 >>>> >>>> Thanks >>>> >>>> Am 03.06.2013 um 13:52 schrieb nek5000-users at lists.mcs.anl.gov: >>>> >>>>> Hi Joerg, >>>>> >>>>> Most likely -- for some reason, the reading routines get a filename ".fld": >>>>> >>>>> 0 1 OPEN: .fld >>>>> .fld >>>>> >>>>> so you might also want to check a value of parameter(67) >>>>> >>>>> Best. >>>>> Aleks >>>>> >>>>> ----- Original Message ----- >>>>> From: nek5000-users at lists.mcs.anl.gov >>>>> To: nek5000-users at lists.mcs.anl.gov >>>>> Sent: Monday, June 3, 2013 5:46:23 AM >>>>> Subject: [Nek5000-users] Problem with multiple file inut >>>>> >>>>> Hi Neks, >>>>> >>>>> we want to run a post processing job analyzing further things of our full production job. >>>>> For output in single file things work well with the following patch of code in the usr file of >>>>> the analysis program: >>>>> >>>>> IF (istep.eq.1) THEN >>>>> >>>>> do k=1,xx >>>>> WRITE(fldfle,'("G1_640.f",I5.5)')k >>>>> initc(1) = trim(fldfle) >>>>> call restart(1) >>>>> >>>>> ?? do your analysis??.. >>>>> >>>>> enddo >>>>> >>>>> ENDIF >>>>> >>>>> It does the analysis for xx snapshots G1_640.f00001 to G1_640.f000xx that we generated >>>>> before. >>>>> >>>>> Bigger jobs requires multiple file outputs, e.g. here each snapshot goes into 4 separate files >>>>> G1_640.f0000x to G1_643.f0000x >>>>> >>>>> I thought that the corresponding extension should do it: >>>>> >>>>> >>>>> IF (istep.eq.1) THEN >>>>> >>>>> do k=1,xx >>>>> k1=4+k >>>>> WRITE(fldfle,'("G1_64?.f",I5.5)')k1 >>>>> initc(1) = trim(fldfle) >>>>> call restart(4) >>>>> >>>>> ?? do your analysis??.. >>>>> >>>>> enddo >>>>> >>>>> ENDIF >>>>> >>>>> >>>>> the patch of log file (see below) indicates that the program reads G1_640.f00005 to G1_643.f00005 correctly and >>>>> gets stuck afterwards when trying to read the four files G1_64*.f00006: >>>>> >>>>> >>>>> >>>>> New CG1-tolerance (RINIT*epsm) = 0.874462285180112059E-17 0.607013350432080170E-25 >>>>> 1 1 Helmholtz VELZ F: 8.7446E-05 1.0000E-06 8.3666E-05 2.0000E+02 >>>>> 1 2 Helmholtz VELZ F: 4.5200E-05 1.0000E-06 8.3666E-05 2.0000E+02 >>>>> 1 3 Helmholtz VELZ F: 3.1000E-05 1.0000E-06 8.3666E-05 2.0000E+02 >>>>> 1 4 Helmholtz VELZ F: 2.4871E-05 1.0000E-06 8.3666E-05 2.0000E+02 >>>>> 1 5 Helmholtz VELZ F: 2.0362E-05 1.0000E-06 8.3666E-05 2.0000E+02 >>>>> 1 6 Helmholtz VELZ F: 1.7312E-05 1.0000E-06 8.3666E-05 2.0000E+02 >>>>> 1 7 Helmholtz VELZ F: 1.4629E-05 1.0000E-06 8.3666E-05 2.0000E+02 >>>>> 1 8 Helmholtz VELZ F: 1.2836E-05 1.0000E-06 8.3666E-05 2.0000E+02 >>>>> 1 9 Helmholtz VELZ F: 1.1274E-05 1.0000E-06 8.3666E-05 2.0000E+02 >>>>> 1 10 Helmholtz VELZ F: 9.7394E-06 1.0000E-06 8.3666E-05 2.0000E+02 >>>>> 1 11 Helmholtz VELZ F: 8.3244E-06 1.0000E-06 8.3666E-05 2.0000E+02 >>>>> 1 12 Helmholtz VELZ F: 6.8927E-06 1.0000E-06 8.3666E-05 2.0000E+02 >>>>> 1 13 Helmholtz VELZ F: 5.5410E-06 1.0000E-06 8.3666E-05 2.0000E+02 >>>>> 1 14 Helmholtz VELZ F: 4.4505E-06 1.0000E-06 8.3666E-05 2.0000E+02 >>>>> 1 15 Helmholtz VELZ F: 3.5729E-06 1.0000E-06 8.3666E-05 2.0000E+02 >>>>> 1 16 Helmholtz VELZ F: 2.8812E-06 1.0000E-06 8.3666E-05 2.0000E+02 >>>>> 1 17 Helmholtz VELZ F: 2.3406E-06 1.0000E-06 8.3666E-05 2.0000E+02 >>>>> 1 18 Helmholtz VELZ F: 1.9136E-06 1.0000E-06 8.3666E-05 2.0000E+02 >>>>> 1 19 Helmholtz VELZ F: 1.5656E-06 1.0000E-06 8.3666E-05 2.0000E+02 >>>>> 1 20 Helmholtz VELZ F: 1.2877E-06 1.0000E-06 8.3666E-05 2.0000E+02 >>>>> 1 21 Helmholtz VELZ F: 1.0656E-06 1.0000E-06 8.3666E-05 2.0000E+02 >>>>> 1 22 Helmholtz VELZ F: 8.8191E-07 1.0000E-06 8.3666E-05 2.0000E+02 >>>>> 1 Hmholtz VELZ: 21 8.8191E-07 8.7446E-05 1.0000E-06 >>>>> L1/L2 DIV(V) : 2.0122E-21 5.8478E-05 >>>>> L1/L2 QTL : 0.0000E+00 0.0000E+00 >>>>> L1/L2 DIV(V)-QTL: 2.0122E-21 5.8478E-05 >>>>> 1 5.0000E-03 2.8596E+00 Fluid done >>>>> filt amp .0000 .0000 .0000 .0000 .0000 .0000 .0000 .0000 .0000 .0000 .0000 .0500 >>>>> filt trn 1.0000 1.0000 1.0000 1.0000 1.0000 1.0000 1.0000 1.0000 1.0000 1.0000 1.0000 .9500 >>>>> 1 5.0000E-03 -1.3839E-88 1.0000E+00 -3.9134E-06 3.9717E-06 uz_t_mx >>>>> Reading checkpoint data >>>>> 0 1 OPEN: G1_640.f00005 >>>>> byte swap: F 6.543210030 -0.2931277218E+36 >>>>> 12288 1 OPEN: G1_643.f00005 >>>>> 4096 1 OPEN: G1_641.f00005 >>>>> 8192 1 OPEN: G1_642.f00005 >>>>> >>>>> 1 2.2370E+02 done :: Read checkpoint data >>>>> avg data-throughput = -80.6MBps >>>>> io-nodes = 4 >>>>> >>>>> 0 1 OPEN: .fld >>>>> .fld >>>>> byte_read() :: fopen failure2! >>>>> >>>>> >>>>> Parameter 65 in the rea file is set to 4. Could it be that the initc is not correctly set? >>>>> >>>>> Thanks a lot, Joerg. >>>>> >>>>> _______________________________________________ >>>>> Nek5000-users mailing list >>>>> Nek5000-users at lists.mcs.anl.gov >>>>> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >>>>> _______________________________________________ >>>>> Nek5000-users mailing list >>>>> Nek5000-users at lists.mcs.anl.gov >>>>> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >>>> >>>> _______________________________________________ >>>> Nek5000-users mailing list >>>> Nek5000-users at lists.mcs.anl.gov >>>> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >>>> _______________________________________________ >>>> Nek5000-users mailing list >>>> Nek5000-users at lists.mcs.anl.gov >>>> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >>> >>> _______________________________________________ >>> Nek5000-users mailing list >>> Nek5000-users at lists.mcs.anl.gov >>> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >>> _______________________________________________ >>> Nek5000-users mailing list >>> Nek5000-users at lists.mcs.anl.gov >>> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >> >> _______________________________________________ >> Nek5000-users mailing list >> Nek5000-users at lists.mcs.anl.gov >> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >> _______________________________________________ >> Nek5000-users mailing list >> Nek5000-users at lists.mcs.anl.gov >> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > -------------- next part -------------- A non-text attachment was scrubbed... Name: mkdirs.c Type: text/x-csrc Size: 1109 bytes Desc: URL: From nek5000-users at lists.mcs.anl.gov Mon Jun 3 09:11:49 2013 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 3 Jun 2013 09:11:49 -0500 (CDT) Subject: [Nek5000-users] Problem with multiple file inut In-Reply-To: References: Message-ID: Hi Joerg, Sorry - just saw this email chain - which makes my previous response senseless. What you're doing looks correct to me. Note that p65 has no role in input, only output (why?). We can start digging into this. Paul On Mon, 3 Jun 2013, nek5000-users at lists.mcs.anl.gov wrote: > Hi Neks, > > we want to run a post processing job analyzing further things of our full production job. > For output in single file things work well with the following patch of code in the usr file of > the analysis program: > > IF (istep.eq.1) THEN > > do k=1,xx > WRITE(fldfle,'("G1_640.f",I5.5)')k > initc(1) = trim(fldfle) > call restart(1) > > ?? do your analysis??.. > > enddo > > ENDIF > > It does the analysis for xx snapshots G1_640.f00001 to G1_640.f000xx that we generated > before. > > Bigger jobs requires multiple file outputs, e.g. here each snapshot goes into 4 separate files > G1_640.f0000x to G1_643.f0000x > > I thought that the corresponding extension should do it: > > > IF (istep.eq.1) THEN > > do k=1,xx > k1=4+k > WRITE(fldfle,'("G1_64?.f",I5.5)')k1 > initc(1) = trim(fldfle) > call restart(4) > > ?? do your analysis??.. > > enddo > > ENDIF > > > the patch of log file (see below) indicates that the program reads G1_640.f00005 to G1_643.f00005 correctly and > gets stuck afterwards when trying to read the four files G1_64*.f00006: > > > > New CG1-tolerance (RINIT*epsm) = 0.874462285180112059E-17 0.607013350432080170E-25 > 1 1 Helmholtz VELZ F: 8.7446E-05 1.0000E-06 8.3666E-05 2.0000E+02 > 1 2 Helmholtz VELZ F: 4.5200E-05 1.0000E-06 8.3666E-05 2.0000E+02 > 1 3 Helmholtz VELZ F: 3.1000E-05 1.0000E-06 8.3666E-05 2.0000E+02 > 1 4 Helmholtz VELZ F: 2.4871E-05 1.0000E-06 8.3666E-05 2.0000E+02 > 1 5 Helmholtz VELZ F: 2.0362E-05 1.0000E-06 8.3666E-05 2.0000E+02 > 1 6 Helmholtz VELZ F: 1.7312E-05 1.0000E-06 8.3666E-05 2.0000E+02 > 1 7 Helmholtz VELZ F: 1.4629E-05 1.0000E-06 8.3666E-05 2.0000E+02 > 1 8 Helmholtz VELZ F: 1.2836E-05 1.0000E-06 8.3666E-05 2.0000E+02 > 1 9 Helmholtz VELZ F: 1.1274E-05 1.0000E-06 8.3666E-05 2.0000E+02 > 1 10 Helmholtz VELZ F: 9.7394E-06 1.0000E-06 8.3666E-05 2.0000E+02 > 1 11 Helmholtz VELZ F: 8.3244E-06 1.0000E-06 8.3666E-05 2.0000E+02 > 1 12 Helmholtz VELZ F: 6.8927E-06 1.0000E-06 8.3666E-05 2.0000E+02 > 1 13 Helmholtz VELZ F: 5.5410E-06 1.0000E-06 8.3666E-05 2.0000E+02 > 1 14 Helmholtz VELZ F: 4.4505E-06 1.0000E-06 8.3666E-05 2.0000E+02 > 1 15 Helmholtz VELZ F: 3.5729E-06 1.0000E-06 8.3666E-05 2.0000E+02 > 1 16 Helmholtz VELZ F: 2.8812E-06 1.0000E-06 8.3666E-05 2.0000E+02 > 1 17 Helmholtz VELZ F: 2.3406E-06 1.0000E-06 8.3666E-05 2.0000E+02 > 1 18 Helmholtz VELZ F: 1.9136E-06 1.0000E-06 8.3666E-05 2.0000E+02 > 1 19 Helmholtz VELZ F: 1.5656E-06 1.0000E-06 8.3666E-05 2.0000E+02 > 1 20 Helmholtz VELZ F: 1.2877E-06 1.0000E-06 8.3666E-05 2.0000E+02 > 1 21 Helmholtz VELZ F: 1.0656E-06 1.0000E-06 8.3666E-05 2.0000E+02 > 1 22 Helmholtz VELZ F: 8.8191E-07 1.0000E-06 8.3666E-05 2.0000E+02 > 1 Hmholtz VELZ: 21 8.8191E-07 8.7446E-05 1.0000E-06 > L1/L2 DIV(V) : 2.0122E-21 5.8478E-05 > L1/L2 QTL : 0.0000E+00 0.0000E+00 > L1/L2 DIV(V)-QTL: 2.0122E-21 5.8478E-05 > 1 5.0000E-03 2.8596E+00 Fluid done > filt amp .0000 .0000 .0000 .0000 .0000 .0000 .0000 .0000 .0000 .0000 .0000 .0500 > filt trn 1.0000 1.0000 1.0000 1.0000 1.0000 1.0000 1.0000 1.0000 1.0000 1.0000 1.0000 .9500 > 1 5.0000E-03 -1.3839E-88 1.0000E+00 -3.9134E-06 3.9717E-06 uz_t_mx > Reading checkpoint data > 0 1 OPEN: G1_640.f00005 > byte swap: F 6.543210030 -0.2931277218E+36 > 12288 1 OPEN: G1_643.f00005 > 4096 1 OPEN: G1_641.f00005 > 8192 1 OPEN: G1_642.f00005 > > 1 2.2370E+02 done :: Read checkpoint data > avg data-throughput = -80.6MBps > io-nodes = 4 > > 0 1 OPEN: .fld > .fld > byte_read() :: fopen failure2! > > > Parameter 65 in the rea file is set to 4. Could it be that the initc is not correctly set? > > Thanks a lot, Joerg. > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > From nek5000-users at lists.mcs.anl.gov Mon Jun 3 10:07:41 2013 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 3 Jun 2013 10:07:41 -0500 (CDT) Subject: [Nek5000-users] Problem with multiple file inut In-Reply-To: Message-ID: Sorry, Joerg, I missed the part of your email where you said " Bigger jobs requires multiple file outputs, e.g. here each snapshot goes into 4 separate files G1_640.f0000x to G1_643.f0000x " so as I understand now, you case works fine while restarting from a single file, i.e. G1_640.f00005, and your question is how to restart from a field written to 4 files G1_64[0-3].f00005 If my understand is (finely :) correct then you need to character*13 fnames c c 1234567890123 c fnames = 'G1_64?.f00005' call chcopy (initc(1),fnames,13) call restart(1) No need to change p67 Aleks ----- Original Message ----- From: nek5000-users at lists.mcs.anl.gov To: nek5000-users at lists.mcs.anl.gov Sent: Monday, June 3, 2013 9:11:49 AM Subject: Re: [Nek5000-users] Problem with multiple file inut Hi Joerg, Sorry - just saw this email chain - which makes my previous response senseless. What you're doing looks correct to me. Note that p65 has no role in input, only output (why?). We can start digging into this. Paul On Mon, 3 Jun 2013, nek5000-users at lists.mcs.anl.gov wrote: > Hi Neks, > > we want to run a post processing job analyzing further things of our full production job. > For output in single file things work well with the following patch of code in the usr file of > the analysis program: > > IF (istep.eq.1) THEN > > do k=1,xx > WRITE(fldfle,'("G1_640.f",I5.5)')k > initc(1) = trim(fldfle) > call restart(1) > > ?? do your analysis??.. > > enddo > > ENDIF > > It does the analysis for xx snapshots G1_640.f00001 to G1_640.f000xx that we generated > before. > > Bigger jobs requires multiple file outputs, e.g. here each snapshot goes into 4 separate files > G1_640.f0000x to G1_643.f0000x > > I thought that the corresponding extension should do it: > > > IF (istep.eq.1) THEN > > do k=1,xx > k1=4+k > WRITE(fldfle,'("G1_64?.f",I5.5)')k1 > initc(1) = trim(fldfle) > call restart(4) > > ?? do your analysis??.. > > enddo > > ENDIF > > > the patch of log file (see below) indicates that the program reads G1_640.f00005 to G1_643.f00005 correctly and > gets stuck afterwards when trying to read the four files G1_64*.f00006: > > > > New CG1-tolerance (RINIT*epsm) = 0.874462285180112059E-17 0.607013350432080170E-25 > 1 1 Helmholtz VELZ F: 8.7446E-05 1.0000E-06 8.3666E-05 2.0000E+02 > 1 2 Helmholtz VELZ F: 4.5200E-05 1.0000E-06 8.3666E-05 2.0000E+02 > 1 3 Helmholtz VELZ F: 3.1000E-05 1.0000E-06 8.3666E-05 2.0000E+02 > 1 4 Helmholtz VELZ F: 2.4871E-05 1.0000E-06 8.3666E-05 2.0000E+02 > 1 5 Helmholtz VELZ F: 2.0362E-05 1.0000E-06 8.3666E-05 2.0000E+02 > 1 6 Helmholtz VELZ F: 1.7312E-05 1.0000E-06 8.3666E-05 2.0000E+02 > 1 7 Helmholtz VELZ F: 1.4629E-05 1.0000E-06 8.3666E-05 2.0000E+02 > 1 8 Helmholtz VELZ F: 1.2836E-05 1.0000E-06 8.3666E-05 2.0000E+02 > 1 9 Helmholtz VELZ F: 1.1274E-05 1.0000E-06 8.3666E-05 2.0000E+02 > 1 10 Helmholtz VELZ F: 9.7394E-06 1.0000E-06 8.3666E-05 2.0000E+02 > 1 11 Helmholtz VELZ F: 8.3244E-06 1.0000E-06 8.3666E-05 2.0000E+02 > 1 12 Helmholtz VELZ F: 6.8927E-06 1.0000E-06 8.3666E-05 2.0000E+02 > 1 13 Helmholtz VELZ F: 5.5410E-06 1.0000E-06 8.3666E-05 2.0000E+02 > 1 14 Helmholtz VELZ F: 4.4505E-06 1.0000E-06 8.3666E-05 2.0000E+02 > 1 15 Helmholtz VELZ F: 3.5729E-06 1.0000E-06 8.3666E-05 2.0000E+02 > 1 16 Helmholtz VELZ F: 2.8812E-06 1.0000E-06 8.3666E-05 2.0000E+02 > 1 17 Helmholtz VELZ F: 2.3406E-06 1.0000E-06 8.3666E-05 2.0000E+02 > 1 18 Helmholtz VELZ F: 1.9136E-06 1.0000E-06 8.3666E-05 2.0000E+02 > 1 19 Helmholtz VELZ F: 1.5656E-06 1.0000E-06 8.3666E-05 2.0000E+02 > 1 20 Helmholtz VELZ F: 1.2877E-06 1.0000E-06 8.3666E-05 2.0000E+02 > 1 21 Helmholtz VELZ F: 1.0656E-06 1.0000E-06 8.3666E-05 2.0000E+02 > 1 22 Helmholtz VELZ F: 8.8191E-07 1.0000E-06 8.3666E-05 2.0000E+02 > 1 Hmholtz VELZ: 21 8.8191E-07 8.7446E-05 1.0000E-06 > L1/L2 DIV(V) : 2.0122E-21 5.8478E-05 > L1/L2 QTL : 0.0000E+00 0.0000E+00 > L1/L2 DIV(V)-QTL: 2.0122E-21 5.8478E-05 > 1 5.0000E-03 2.8596E+00 Fluid done > filt amp .0000 .0000 .0000 .0000 .0000 .0000 .0000 .0000 .0000 .0000 .0000 .0500 > filt trn 1.0000 1.0000 1.0000 1.0000 1.0000 1.0000 1.0000 1.0000 1.0000 1.0000 1.0000 .9500 > 1 5.0000E-03 -1.3839E-88 1.0000E+00 -3.9134E-06 3.9717E-06 uz_t_mx > Reading checkpoint data > 0 1 OPEN: G1_640.f00005 > byte swap: F 6.543210030 -0.2931277218E+36 > 12288 1 OPEN: G1_643.f00005 > 4096 1 OPEN: G1_641.f00005 > 8192 1 OPEN: G1_642.f00005 > > 1 2.2370E+02 done :: Read checkpoint data > avg data-throughput = -80.6MBps > io-nodes = 4 > > 0 1 OPEN: .fld > .fld > byte_read() :: fopen failure2! > > > Parameter 65 in the rea file is set to 4. Could it be that the initc is not correctly set? > > Thanks a lot, Joerg. > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Mon Jun 3 10:13:51 2013 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 3 Jun 2013 17:13:51 +0200 Subject: [Nek5000-users] Problem with multiple file inut In-Reply-To: References: Message-ID: Dear Aleks, thanks I will try this out. Joerg. Am 03.06.2013 um 17:07 schrieb nek5000-users at lists.mcs.anl.gov: > Sorry, Joerg, > > I missed the part of your email where you said > > " > Bigger jobs requires multiple file outputs, e.g. here each snapshot goes into 4 separate files G1_640.f0000x to G1_643.f0000x > " > > so as I understand now, you case works fine while restarting from a single file, i.e. G1_640.f00005, and your question is how to restart from a field written to 4 files G1_64[0-3].f00005 > > If my understand is (finely :) correct then you need to > > character*13 fnames > c > c 1234567890123 > c > fnames = 'G1_64?.f00005' > > call chcopy (initc(1),fnames,13) > call restart(1) > > No need to change p67 > > Aleks > > > ----- Original Message ----- > From: nek5000-users at lists.mcs.anl.gov > To: nek5000-users at lists.mcs.anl.gov > Sent: Monday, June 3, 2013 9:11:49 AM > Subject: Re: [Nek5000-users] Problem with multiple file inut > > > Hi Joerg, > > Sorry - just saw this email chain - which makes my previous > response senseless. > > What you're doing looks correct to me. > > Note that p65 has no role in input, only output (why?). > > We can start digging into this. > > Paul > > > > > > On Mon, 3 Jun 2013, nek5000-users at lists.mcs.anl.gov wrote: > >> Hi Neks, >> >> we want to run a post processing job analyzing further things of our full production job. >> For output in single file things work well with the following patch of code in the usr file of >> the analysis program: >> >> IF (istep.eq.1) THEN >> >> do k=1,xx >> WRITE(fldfle,'("G1_640.f",I5.5)')k >> initc(1) = trim(fldfle) >> call restart(1) >> >> ?? do your analysis??.. >> >> enddo >> >> ENDIF >> >> It does the analysis for xx snapshots G1_640.f00001 to G1_640.f000xx that we generated >> before. >> >> Bigger jobs requires multiple file outputs, e.g. here each snapshot goes into 4 separate files >> G1_640.f0000x to G1_643.f0000x >> >> I thought that the corresponding extension should do it: >> >> >> IF (istep.eq.1) THEN >> >> do k=1,xx >> k1=4+k >> WRITE(fldfle,'("G1_64?.f",I5.5)')k1 >> initc(1) = trim(fldfle) >> call restart(4) >> >> ?? do your analysis??.. >> >> enddo >> >> ENDIF >> >> >> the patch of log file (see below) indicates that the program reads G1_640.f00005 to G1_643.f00005 correctly and >> gets stuck afterwards when trying to read the four files G1_64*.f00006: >> >> >> >> New CG1-tolerance (RINIT*epsm) = 0.874462285180112059E-17 0.607013350432080170E-25 >> 1 1 Helmholtz VELZ F: 8.7446E-05 1.0000E-06 8.3666E-05 2.0000E+02 >> 1 2 Helmholtz VELZ F: 4.5200E-05 1.0000E-06 8.3666E-05 2.0000E+02 >> 1 3 Helmholtz VELZ F: 3.1000E-05 1.0000E-06 8.3666E-05 2.0000E+02 >> 1 4 Helmholtz VELZ F: 2.4871E-05 1.0000E-06 8.3666E-05 2.0000E+02 >> 1 5 Helmholtz VELZ F: 2.0362E-05 1.0000E-06 8.3666E-05 2.0000E+02 >> 1 6 Helmholtz VELZ F: 1.7312E-05 1.0000E-06 8.3666E-05 2.0000E+02 >> 1 7 Helmholtz VELZ F: 1.4629E-05 1.0000E-06 8.3666E-05 2.0000E+02 >> 1 8 Helmholtz VELZ F: 1.2836E-05 1.0000E-06 8.3666E-05 2.0000E+02 >> 1 9 Helmholtz VELZ F: 1.1274E-05 1.0000E-06 8.3666E-05 2.0000E+02 >> 1 10 Helmholtz VELZ F: 9.7394E-06 1.0000E-06 8.3666E-05 2.0000E+02 >> 1 11 Helmholtz VELZ F: 8.3244E-06 1.0000E-06 8.3666E-05 2.0000E+02 >> 1 12 Helmholtz VELZ F: 6.8927E-06 1.0000E-06 8.3666E-05 2.0000E+02 >> 1 13 Helmholtz VELZ F: 5.5410E-06 1.0000E-06 8.3666E-05 2.0000E+02 >> 1 14 Helmholtz VELZ F: 4.4505E-06 1.0000E-06 8.3666E-05 2.0000E+02 >> 1 15 Helmholtz VELZ F: 3.5729E-06 1.0000E-06 8.3666E-05 2.0000E+02 >> 1 16 Helmholtz VELZ F: 2.8812E-06 1.0000E-06 8.3666E-05 2.0000E+02 >> 1 17 Helmholtz VELZ F: 2.3406E-06 1.0000E-06 8.3666E-05 2.0000E+02 >> 1 18 Helmholtz VELZ F: 1.9136E-06 1.0000E-06 8.3666E-05 2.0000E+02 >> 1 19 Helmholtz VELZ F: 1.5656E-06 1.0000E-06 8.3666E-05 2.0000E+02 >> 1 20 Helmholtz VELZ F: 1.2877E-06 1.0000E-06 8.3666E-05 2.0000E+02 >> 1 21 Helmholtz VELZ F: 1.0656E-06 1.0000E-06 8.3666E-05 2.0000E+02 >> 1 22 Helmholtz VELZ F: 8.8191E-07 1.0000E-06 8.3666E-05 2.0000E+02 >> 1 Hmholtz VELZ: 21 8.8191E-07 8.7446E-05 1.0000E-06 >> L1/L2 DIV(V) : 2.0122E-21 5.8478E-05 >> L1/L2 QTL : 0.0000E+00 0.0000E+00 >> L1/L2 DIV(V)-QTL: 2.0122E-21 5.8478E-05 >> 1 5.0000E-03 2.8596E+00 Fluid done >> filt amp .0000 .0000 .0000 .0000 .0000 .0000 .0000 .0000 .0000 .0000 .0000 .0500 >> filt trn 1.0000 1.0000 1.0000 1.0000 1.0000 1.0000 1.0000 1.0000 1.0000 1.0000 1.0000 .9500 >> 1 5.0000E-03 -1.3839E-88 1.0000E+00 -3.9134E-06 3.9717E-06 uz_t_mx >> Reading checkpoint data >> 0 1 OPEN: G1_640.f00005 >> byte swap: F 6.543210030 -0.2931277218E+36 >> 12288 1 OPEN: G1_643.f00005 >> 4096 1 OPEN: G1_641.f00005 >> 8192 1 OPEN: G1_642.f00005 >> >> 1 2.2370E+02 done :: Read checkpoint data >> avg data-throughput = -80.6MBps >> io-nodes = 4 >> >> 0 1 OPEN: .fld >> .fld >> byte_read() :: fopen failure2! >> >> >> Parameter 65 in the rea file is set to 4. Could it be that the initc is not correctly set? >> >> Thanks a lot, Joerg. >> >> _______________________________________________ >> Nek5000-users mailing list >> Nek5000-users at lists.mcs.anl.gov >> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >> > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Tue Jun 4 05:38:58 2013 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 4 Jun 2013 12:38:58 +0200 Subject: [Nek5000-users] Prenek and Genbox - Maketools problems Message-ID: Hello All, Any follow up on the Prenek problems I was discussing please? Thank you in advance, JP -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Tue Jun 4 05:58:47 2013 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 4 Jun 2013 05:58:47 -0500 (CDT) Subject: [Nek5000-users] Prenek and Genbox - Maketools problems In-Reply-To: Message-ID: Dear JP, In prex, the cursor focus and typed responses should be inside the X-window, not in the text window. I usually keep the text window visible however because often the prompts are clipped in the X-window. ?So you read the questions from the text window, but type the response in the X-window. What type of geometry are you trying to build with prex ? ?We might be able to assist in getting you started. Best regards, Paul ----- Original Message ----- From: nek5000-users at lists.mcs.anl.gov To: "nek5000-users" Sent: Saturday, May 25, 2013 12:42:03 PM Subject: Re: [Nek5000-users] Prenek and Genbox - Maketools problems Hi Katie, Thanks, genbox is creating the .re2 file without any errors now and you are right regrading the IO error.. it appears since I close prex by just closing the window. Regarding what's happening with PRENEK: in general, for 'PREX', it prints the following error every time when opening: 'I/O Error: No String Terminator sent to PRS' Then when I input a name for the session (after the prompt "Choose a Name for This Session:" ) the program does nothing. It doesn't take the session name and I can keep on typing text and pressing enter with no response. On the other hand, for 'PRETEX', it doesn't show the 'I/O Error: No String Terminator sent to PRS' at the beginning but gives: 'cp: cannot stat `/home/jpm/.nekdefaults': No such file or directory' It lets me input a session name and this time it accepts it and i manage to go through the menu options but when trying to 'read previous parameters' it gives 'Error reading parameters from file.' When I try the 'Type in new parameters' it lets me carry on but when I try to 'Build interactively' the following message appears: 'Error: Grid must be between 0 and 1 (fraction of Screen height). Screen gridding couldnt be changed drwobjs: 0' I then go through some stages, and manage to, for example, use the 'Import Mesh' but the mesh is not imported correctly and grey boxes appear (which I imagine should be clickable options) but there is nothing inside them. Other options seem to work partially but never successfully, it is as though there is something wrong with the output to the Nekton window. Sorry if the above is confusing but I tried to summarise what is happening. Thank you, JP _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Thu Jun 6 06:37:38 2013 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 6 Jun 2013 13:37:38 +0200 Subject: [Nek5000-users] Prenek and Genbox - Maketools problems Message-ID: Dear Paul, Thanks. By typing in the X-window as you suggested I have managed to start using Prenek to create some geometries, mesh, create curved sides etc. etc. Basically I'm trying out the various options there are and getting used to them. One problem is that in the X-window, the text of the menu items does not appear. I.e. I only see grey boxes and must click on the correct box by clicking on the 3rd box if for example I need the 3rd menu item. Also, is it also normal that the X-window does not size well into the screen and some of it is outside the screen? Note: The error messages ''I/O Error: No String Terminator sent to PRS' still appear. Thank you, JP -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Thu Jun 6 07:01:20 2013 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 6 Jun 2013 07:01:20 -0500 (CDT) Subject: [Nek5000-users] Prenek and Genbox - Maketools problems In-Reply-To: Message-ID: Hi JP, The window size in Prenek is set in prenek/xdriver.c with windowh & windoww. Best. Aleks ----- Original Message ----- From: nek5000-users at lists.mcs.anl.gov To: "nek5000-users" Sent: Thursday, June 6, 2013 6:37:38 AM Subject: Re: [Nek5000-users] Prenek and Genbox - Maketools problems Dear Paul, Thanks. By typing in the X-window as you suggested I have managed to start using Prenek to create some geometries, mesh, create curved sides etc. etc. Basically I'm trying out the various options there are and getting used to them. One problem is that in the X-window, the text of the menu items does not appear. I.e. I only see grey boxes and must click on the correct box by clicking on the 3rd box if for example I need the 3rd menu item. Also, is it also normal that the X-window does not size well into the screen and some of it is outside the screen? Note: The error messages ' 'I/O Error: No String Terminator sent to PRS' still appear. Thank you, JP _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Thu Jun 6 07:37:56 2013 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 6 Jun 2013 14:37:56 +0200 Subject: [Nek5000-users] Problem with multiple file inut In-Reply-To: References: Message-ID: Hi Neks, just to give a positive feedback to this problem: Output into single file G1_640.f00001 during production job requires the following loop for post processing IF (istep.eq.1) THEN do k=1,1 WRITE(fldfle,'("G1_640.f",I5.5)')k initc(1) = trim(fldfle) call restart(1) ?.. do analysis with data from G1_640.f00001 enddo ENDIF Output into multiple files G1_64x.f00001 during production job requires the following loop for post processing character*13 fnames IF (istep.eq.1) THEN do k=1,1 WRITE(fldfle,'("G1_64?.f",I5.5)')k fnames = trim(fldfle) call chcopy(initc(1),fnames,13) call restart(1) ?.. do analysis with data from G1_64x.f00001 enddo ENDIF Thanks once more Aleks and Paul. Best wishes, Joerg. From nek5000-users at lists.mcs.anl.gov Thu Jun 6 08:06:00 2013 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 6 Jun 2013 08:06:00 -0500 (CDT) Subject: [Nek5000-users] Problem with multiple file inut In-Reply-To: Message-ID: Great to hear, Joerg! Aleks ----- Original Message ----- From: nek5000-users at lists.mcs.anl.gov To: nek5000-users at lists.mcs.anl.gov Cc: "Janet Scheel" Sent: Thursday, June 6, 2013 7:37:56 AM Subject: Re: [Nek5000-users] Problem with multiple file inut Hi Neks, just to give a positive feedback to this problem: Output into single file G1_640.f00001 during production job requires the following loop for post processing IF (istep.eq.1) THEN do k=1,1 WRITE(fldfle,'("G1_640.f",I5.5)')k initc(1) = trim(fldfle) call restart(1) ?.. do analysis with data from G1_640.f00001 enddo ENDIF Output into multiple files G1_64x.f00001 during production job requires the following loop for post processing character*13 fnames IF (istep.eq.1) THEN do k=1,1 WRITE(fldfle,'("G1_64?.f",I5.5)')k fnames = trim(fldfle) call chcopy(initc(1),fnames,13) call restart(1) ?.. do analysis with data from G1_64x.f00001 enddo ENDIF Thanks once more Aleks and Paul. Best wishes, Joerg. _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Thu Jun 6 09:26:02 2013 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Thu, 6 Jun 2013 09:26:02 -0500 Subject: [Nek5000-users] Prenek and Genbox - Maketools problems In-Reply-To: References: Message-ID: Hi JP, What OS are you using? I solved the issue with the text on a GNU/Linux system by installing all of the font packages. Justin On Thu, 6 Jun 2013 07:01:20 -0500 (CDT) nek5000-users at lists.mcs.anl.gov wrote: > Hi JP, > > The window size in Prenek is set in prenek/xdriver.c with windowh & > windoww. > > Best. > Aleks > > ----- Original Message ----- > From: nek5000-users at lists.mcs.anl.gov > To: "nek5000-users" > Sent: Thursday, June 6, 2013 6:37:38 AM > Subject: Re: [Nek5000-users] Prenek and Genbox - Maketools problems > > > > Dear Paul, > > > Thanks. By typing in the X-window as you suggested I have managed to > start using Prenek to create some geometries, mesh, create curved > sides etc. etc. Basically I'm trying out the various options there > are and getting used to them. > > > One problem is that in the X-window, the text of the menu items does > not appear. I.e. I only see grey boxes and must click on the correct > box by clicking on the 3rd box if for example I need the 3rd menu > item. Also, is it also normal that the X-window does not size well > into the screen and some of it is outside the screen? > > > Note: The error messages ' 'I/O Error: No String Terminator sent to > PRS' still appear. > > > Thank you, > JP > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Fri Jun 7 05:27:36 2013 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 7 Jun 2013 12:27:36 +0200 Subject: [Nek5000-users] Prenek and Genbox - Maketools problems Message-ID: Hi All, Aleks - thank you for the tip for changing Prenek's window size. Justin - Re: The text not showing on menu items - I am using Ubuntu. I have tried to install many different types of fonts but the text is still not showing. Which font packages did you install to solve the issue? The ''I/O Error: No String Terminator sent to PRS' still appears too. Thanks, JP -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Fri Jun 7 13:55:56 2013 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 7 Jun 2013 13:55:56 -0500 Subject: [Nek5000-users] Prenek and Genbox - Maketools problems In-Reply-To: References: Message-ID: Hi JP, If you want to test my idea, you can just install all of the ubuntu packages beginning with "fonts-". It's been awhile since I used Ubuntu, so I can't help you with the install syntax, usually apt-get or dpkg... If installing all of them fixes it, then we can try and narrow down which one is necessary. For example, you'll pull in everything, but Chinese true type fonts won't be what we're looking for.... Does this make sense? Best, Justin On Fri, Jun 7, 2013 at 5:27 AM, wrote: > Hi All, > > Aleks - thank you for the tip for changing Prenek's window size. > > Justin - Re: The text not showing on menu items - I am using Ubuntu. I have > tried to install many different types of fonts but the text is still not > showing. Which font packages did you install to solve the issue? > > The ''I/O Error: No String Terminator sent to PRS' still appears too. > > Thanks, > JP > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > From nek5000-users at lists.mcs.anl.gov Mon Jun 10 05:03:18 2013 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 10 Jun 2013 12:03:18 +0200 Subject: [Nek5000-users] Prenek and Genbox - Maketools problems Message-ID: Hi Justin and All, After trying out several font packages (through Synaptic in Ubuntu), I have finally found the ones I had missing that are needed for the menu items' text in Prenek to show. They are: xfonts-100dpi (100 dpi fonts for X) xfonts-75dpi (75 dpi fonts for X) Thanks and regards, JP -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Mon Jun 10 09:04:25 2013 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 10 Jun 2013 16:04:25 +0200 Subject: [Nek5000-users] Import VTK in Prenek from Gmsh Message-ID: Dear All, I have searched the mail archive and found that it is possible to import .vtk meshes into Prenek. I couldn't find what modifications need to be done to the .vtk file for Prenek to read it though. I get this error when trying to import the file into Prenek: " At line 1666 of file build.f (unit = 47, file = 'gmsh_1') Fortran runtime error: Bad integer for item 1 in list input " What must be modified for Prenek to import the file? Find attached the file i'm trying to import. Thank you, JP -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: gmsh_1 Type: application/octet-stream Size: 21462 bytes Desc: not available URL: From nek5000-users at lists.mcs.anl.gov Fri Jun 14 11:08:58 2013 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 14 Jun 2013 18:08:58 +0200 Subject: [Nek5000-users] New multigrid for pn-pn Message-ID: Dear NEKs I have been using Pn-Pn with the old multigrid method. Though trying to speed up the process I would like to use the updated version of multigrid for the Pn-Pn solver. I was wondering if I need to do something special to make it work. Many thanks in advance Azad From nek5000-users at lists.mcs.anl.gov Fri Jun 14 11:31:36 2013 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 14 Jun 2013 11:31:36 -0500 (CDT) Subject: [Nek5000-users] New multigrid for pn-pn In-Reply-To: Message-ID: Dear Azad, Have you tried the most recent version of the repo with the latest multigrid? To use the new SEMG you would simply make certain that p41--44 are zero in the .rea file. I updated the repo just a couple of weeks back. The SEMG is improved, but it might not make a difference in your particular case. Please let me know if the current SEMG works for you. Best regards, Paul ----- Original Message ----- From: nek5000-users at lists.mcs.anl.gov To: nek5000-users at lists.mcs.anl.gov Sent: Friday, June 14, 2013 11:08:58 AM Subject: Re: [Nek5000-users] New multigrid for pn-pn Dear NEKs I have been using Pn-Pn with the old multigrid method. Though trying to speed up the process I would like to use the updated version of multigrid for the Pn-Pn solver. I was wondering if I need to do something special to make it work. Many thanks in advance Azad _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Fri Jun 14 12:04:32 2013 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 14 Jun 2013 19:04:32 +0200 Subject: [Nek5000-users] Import VTK in Prenek from Gmsh Message-ID: Dear All, Any help on this matter please? Thank you, JP -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Fri Jun 14 16:05:01 2013 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 14 Jun 2013 16:05:01 -0500 (CDT) Subject: [Nek5000-users] Import VTK in Prenek from Gmsh In-Reply-To: References: Message-ID: JP, do you have an ascii example of the file format you wish to load (preferably small) ? Best, Paul On Fri, 14 Jun 2013, nek5000-users at lists.mcs.anl.gov wrote: > Dear All, > > Any help on this matter please? > > Thank you, > JP > From nek5000-users at lists.mcs.anl.gov Sat Jun 15 13:33:01 2013 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Sat, 15 Jun 2013 20:33:01 +0200 Subject: [Nek5000-users] Import VTK in Prenek from Gmsh Message-ID: Dear Paul, Yes I had attached it in the first message ( http://lists.mcs.anl.gov/pipermail/nek5000-users/attachments/20130610/f1848826/attachment-0001.obj ) in the thread but I re-attached it with this message too. Thanks in advance, JP -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: gmsh_1 Type: application/octet-stream Size: 21462 bytes Desc: not available URL: From nek5000-users at lists.mcs.anl.gov Sat Jun 22 11:52:54 2013 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Sat, 22 Jun 2013 18:52:54 +0200 Subject: [Nek5000-users] Full restart during a simulation Message-ID: Hi NEKs, I'm trying to mimic the full restart routine during a simulation. Maybe I can explain better with an example Consider the 2D flow around a circular cylinder. I'm copyng the solutions of four timesteps (istep= 20-23) in an array, then i copy them in four successive timesteps (istep=30,33). I'm expecting that the solution at istep= 34 is the same of istep=24 but it is slightly different (looking for example at drag coefficient). Maybe I have to call same routines that are involved in the restart process but I couldn't find which. Andrea -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Sun Jun 23 12:18:09 2013 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Sun, 23 Jun 2013 19:18:09 +0200 Subject: [Nek5000-users] Import VTK in Prenek from Gmsh Message-ID: Dear All, Any reply on the VTK format please? Thank you in advance, JP -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Sun Jun 23 12:37:59 2013 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Sun, 23 Jun 2013 12:37:59 -0500 (CDT) Subject: [Nek5000-users] Import VTK in Prenek from Gmsh In-Reply-To: Message-ID: Hi JP, I am sorry for the delay -- I am still working on it. Best. Aleks ----- Original Message ----- From: nek5000-users at lists.mcs.anl.gov To: "nek5000-users" Sent: Sunday, June 23, 2013 12:18:09 PM Subject: Re: [Nek5000-users] Import VTK in Prenek from Gmsh Dear All, Any reply on the VTK format please? Thank you in advance, JP _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Mon Jun 24 08:18:52 2013 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 24 Jun 2013 15:18:52 +0200 Subject: [Nek5000-users] Full restart during a simulation Message-ID: Hi Neks, I manage to solve part of the issue. Now I'm copyng all the variables (vx, vxlag, pr ,prlag, abx1,abx2) at a certain step (let's say istep=10). At istep=20 I replace the variables with the old ones and I call the routines setup_convect to save the new convective velocities. For a simulation with no moving boundaries the procedure works fine. I tried to use the same method also for a simulation where I have a moving boundary (forcing the regenation of the jacobians with call geom_reset(1)), but I have correct results only if I set torder=1. Any hints? Andrea subroutine userchk include 'SIZE' include 'TOTAL' include 'RESTART' parameter (lt=lx1*ly1*lz1*lelv) common /scrns/ vort(lt,3), w1(lt), w2(lt) common /body/ ycyl,ycylold,vcyl,vcylold,vcylk,vrif real x0(3) save x0 data x0 /3*0/ real scale integer iostept integer maxsotiter common /indici/ indcyl(lx1,ly1,lz1,lelv) common /contatori/ icont,istepold,timeold integer icont, istepold,n,npre,firstit common /olddati/ vxo(lx1,ly1,lz1,lelv),vyo(lx1,ly1,lz1,lelv), $ vzo(lx1,ly1,lz1,lelv),xm1o(lx1,ly1,lz1,lelv), $ ym1o(lx1,ly1,lz1,lelv),zm1o(lx1,ly1,lz1,lelv), $ vxlago(lx1,ly1,lz1,lelv,2),vylago(lx1,ly1,lz1,lelv,2), $ vzlago(lx1,ly1,lz1,lelv,2) $ , ABX1o (LX1,LY1,LZ1,LELV) $ , ABY1o (LX1,LY1,LZ1,LELV) $ , ABZ1o (LX1,LY1,LZ1,LELV) $ , ABX2o (LX1,LY1,LZ1,LELV) $ , ABY2o (LX1,LY1,LZ1,LELV) $ , ABZ2o (LX1,LY1,LZ1,LELV) $ , PRLAGo (LX2,LY2,LZ2,LELV,LORDER2),pro(lx2,ly2,lz2,lelv) $ , wxo(lx1m,ly1m,lz1m,lelt),wyo(lx1m,ly1m,lz1m,lelt), $ wzo(lx1m,ly1m,lz1m,lelt) $ , WXLAGo (LX1M,LY1M,LZ1M,LELT,LORDER-1) $ , WYLAGo (LX1M,LY1M,LZ1M,LELT,LORDER-1) $ , WZLAGo (LX1M,LY1M,LZ1M,LELT,LORDER-1) $ , W1MASKo(LX1M,LY1M,LZ1M,LELT) $ , W2MASKo(LX1M,LY1M,LZ1M,LELT) $ , W3MASKo(LX1M,LY1M,LZ1M,LELT) $ , WMULTo (LX1M,LY1M,LZ1M,LELT) real alpha real tollit real errvc integer npcyl if (istep.eq.0) then call findcyl(indcyl) endif scale=1. call evalYcyl write(6,*) "ycyl=",ycyl n=lx1*ly1*lz1*lelv npre=lx2*ly2*lz2*lelv if (istep.eq.10) then call copy_step endif if(istep.eq.20) then call load_step endif call torque_calc(scale,x0,.true.,.false.) return end c ------------------------------------------------------------------------- subroutine copy_step include 'SIZE' include 'TOTAL' include 'RESTART' common /indici/ indcyl(lx1,ly1,lz1,lelv) common /contatori/ icont,istepold,timeold,firstit integer icont, istepold,n,npre,firstit common /olddati/ vxo(lx1,ly1,lz1,lelv),vyo(lx1,ly1,lz1,lelv), $ vzo(lx1,ly1,lz1,lelv),xm1o(lx1,ly1,lz1,lelv), $ ym1o(lx1,ly1,lz1,lelv),zm1o(lx1,ly1,lz1,lelv), $ vxlago(lx1,ly1,lz1,lelv,2),vylago(lx1,ly1,lz1,lelv,2), $ vzlago(lx1,ly1,lz1,lelv,2) $ , ABX1o (LX1,LY1,LZ1,LELV) $ , ABY1o (LX1,LY1,LZ1,LELV) $ , ABZ1o (LX1,LY1,LZ1,LELV) $ , ABX2o (LX1,LY1,LZ1,LELV) $ , ABY2o (LX1,LY1,LZ1,LELV) $ , ABZ2o (LX1,LY1,LZ1,LELV) $ , PRLAGo (LX2,LY2,LZ2,LELV,LORDER2),pro(lx2,ly2,lz2,lelv) $ , wxo(lx1m,ly1m,lz1m,lelt),wyo(lx1m,ly1m,lz1m,lelt), $ wzo(lx1m,ly1m,lz1m,lelt) $ , WXLAGo (LX1M,LY1M,LZ1M,LELT,LORDER-1) $ , WYLAGo (LX1M,LY1M,LZ1M,LELT,LORDER-1) $ , WZLAGo (LX1M,LY1M,LZ1M,LELT,LORDER-1) $ , W1MASKo(LX1M,LY1M,LZ1M,LELT) $ , W2MASKo(LX1M,LY1M,LZ1M,LELT) $ , W3MASKo(LX1M,LY1M,LZ1M,LELT) $ , WMULTo (LX1M,LY1M,LZ1M,LELT), fyold n=lx1*ly1*lz1*lelv npre=lx2*ly2*lz2*lelv call opcopy(vxo,vyo,vzo,vx,vy,vz) call opcopy(wxo,wyo,wzo,wx,wy,wz) do i=1,lorder-1 call opcopy(vxlago(1,1,1,1,i),vylago(1,1,1,1,i), $ vzlago(1,1,1,1,i),vxlag(1,1,1,1,i),vylag(1,1,1,1,i), $ vzlag(1,1,1,1,i)) call opcopy(wxlago(1,1,1,1,i),wylago(1,1,1,1,i), $ wzlago(1,1,1,1,i),wxlag(1,1,1,1,i),wylag(1,1,1,1,i), $ wzlag(1,1,1,1,i)) enddo call copy(w1masko,w1mask,n) call copy(w2masko,w2mask,n) call copy(w3masko,w3mask,n) call copy(wmulto,wmult,n) call copy(abx1o,abx1,n) call copy(aby1o,aby1,n) call copy(abz1o,abz1,n) call copy(abx2o,abx2,n) call copy(aby2o,aby2,n) call copy(abz2o,abz2,n) do i=1,lorder2 call copy(prlago(1,1,1,1,i),prlag(1,1,1,1,i),npre) enddo call copy(pro,pr,npre) call opcopy(xm1o,ym1o,zm1o,xm1,ym1,zm1) return end c-------------------------------------------- subroutine load_step include 'SIZE' include 'TOTAL' include 'RESTART' parameter (lt=lx1*ly1*lz1*lelv) common /indici/ indcyl(lx1,ly1,lz1,lelv) common /contatori/ icont,istepold,timeold,firstit integer icont, istepold,n,npre,firstit common /olddati/ vxo(lx1,ly1,lz1,lelv),vyo(lx1,ly1,lz1,lelv), $ vzo(lx1,ly1,lz1,lelv),xm1o(lx1,ly1,lz1,lelv), $ ym1o(lx1,ly1,lz1,lelv),zm1o(lx1,ly1,lz1,lelv), $ vxlago(lx1,ly1,lz1,lelv,2),vylago(lx1,ly1,lz1,lelv,2), $ vzlago(lx1,ly1,lz1,lelv,2) $ , ABX1o (LX1,LY1,LZ1,LELV) $ , ABY1o (LX1,LY1,LZ1,LELV) $ , ABZ1o (LX1,LY1,LZ1,LELV) $ , ABX2o (LX1,LY1,LZ1,LELV) $ , ABY2o (LX1,LY1,LZ1,LELV) $ , ABZ2o (LX1,LY1,LZ1,LELV) $ , PRLAGo (LX2,LY2,LZ2,LELV,LORDER2),pro(lx2,ly2,lz2,lelv) $ , wxo(lx1m,ly1m,lz1m,lelt),wyo(lx1m,ly1m,lz1m,lelt), $ wzo(lx1m,ly1m,lz1m,lelt) $ , WXLAGo (LX1M,LY1M,LZ1M,LELT,LORDER-1) $ , WYLAGo (LX1M,LY1M,LZ1M,LELT,LORDER-1) $ , WZLAGo (LX1M,LY1M,LZ1M,LELT,LORDER-1) $ , W1MASKo(LX1M,LY1M,LZ1M,LELT) $ , W2MASKo(LX1M,LY1M,LZ1M,LELT) $ , W3MASKo(LX1M,LY1M,LZ1M,LELT) $ , WMULTo (LX1M,LY1M,LZ1M,LELT), fyold n=lx1*ly1*lz1*lelv npre=lx2*ly2*lz2*lelv call opcopy(vx,vy,vz,vxo,vyo,vzo) call opcopy(wx,wy,wz,wxo,wyo,wzo) do i=1,lorder-1 call opcopy(vxlag(1,1,1,1,i),vylag(1,1,1,1,i), $ vzlag(1,1,1,1,i),vxlago(1,1,1,1,i),vylago(1,1,1,1,i), $ vzlago(1,1,1,1,i)) call opcopy(wxlag(1,1,1,1,i),wylag(1,1,1,1,i), $ wzlag(1,1,1,1,i),wxlago(1,1,1,1,i),wylago(1,1,1,1,i), $ wzlago(1,1,1,1,i)) enddo call copy(abz1,abz1o,n) call copy(abx1,abx1o,n) call copy(aby1,aby1o,n) call copy(abz1,abz1o,n) call copy(abx2,abx2o,n) call copy(aby2,aby2o,n) call copy(abz2,abz2o,n) call copy(w1mask,w1masko,n) call copy(w2mask,w2masko,n) call copy(w3mask,w3masko,n) call copy(wmult,wmulto,n) do i=1,lorder2 call copy(prlag(1,1,1,1,i),prlago(1,1,1,1,i),npre) enddo call copy(pr,pro,npre) call opcopy(xm1,ym1,zm1,xm1o,ym1o,zm1o) call geom_reset(1) call setup_convect(1) call setup_convect(2) c call setup_convect(3) return end -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Mon Jun 24 09:17:51 2013 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Mon, 24 Jun 2013 09:17:51 -0500 (CDT) Subject: [Nek5000-users] Full restart during a simulation In-Reply-To: Message-ID: Hi Andrea, I'm glad you're making progress. Like you, I was surprised that just copying pressure & velocity for 4 timesteps did not suffice. It should, in my opinion, but I've not had a chance to figure out why just yet. Regarding moving meshes, there are mass matrices to be lagged (bm1lag), and of course you'll need to store the geometry, just as you did velocity/pressure. There may be some other arrays but I can't think of exactly which those would be at the moment. A quick grep -i lag *.f | grep -v Lagrang shows several.... I notice "dtlag()" ... which would be important if you don't have fixed dt. Paul ----- Original Message ----- From: nek5000-users at lists.mcs.anl.gov To: nek5000-users at lists.mcs.anl.gov Sent: Monday, June 24, 2013 8:18:52 AM Subject: Re: [Nek5000-users] Full restart during a simulation Hi Neks, I manage to solve part of the issue. Now I'm copyng all the variables (vx, vxlag, pr ,prlag, abx1,abx2) at a certain step (let's say istep=10). At istep=20 I replace the variables with the old ones and I call the routines setup_convect to save the new convective velocities. For a simulation with no moving boundaries the procedure works fine. I tried to use the same method also for a simulation where I have a moving boundary (forcing the regenation of the jacobians with call geom_reset(1)), but I have correct results only if I set torder=1. Any hints? Andrea subroutine userchk include 'SIZE' include 'TOTAL' include 'RESTART' parameter (lt=lx1*ly1*lz1*lelv) common /scrns/ vort(lt,3), w1(lt), w2(lt) common /body/ ycyl,ycylold,vcyl,vcylold,vcylk,vrif real x0(3) save x0 data x0 /3*0/ real scale integer iostept integer maxsotiter common /indici/ indcyl(lx1,ly1,lz1,lelv) common /contatori/ icont,istepold,timeold integer icont, istepold,n,npre,firstit common /olddati/ vxo(lx1,ly1,lz1,lelv),vyo(lx1,ly1,lz1,lelv), $ vzo(lx1,ly1,lz1,lelv),xm1o(lx1,ly1,lz1,lelv), $ ym1o(lx1,ly1,lz1,lelv),zm1o(lx1,ly1,lz1,lelv), $ vxlago(lx1,ly1,lz1,lelv,2),vylago(lx1,ly1,lz1,lelv,2), $ vzlago(lx1,ly1,lz1,lelv,2) $ , ABX1o (LX1,LY1,LZ1,LELV) $ , ABY1o (LX1,LY1,LZ1,LELV) $ , ABZ1o (LX1,LY1,LZ1,LELV) $ , ABX2o (LX1,LY1,LZ1,LELV) $ , ABY2o (LX1,LY1,LZ1,LELV) $ , ABZ2o (LX1,LY1,LZ1,LELV) $ , PRLAGo (LX2,LY2,LZ2,LELV,LORDER2),pro(lx2,ly2,lz2,lelv) $ , wxo(lx1m,ly1m,lz1m,lelt),wyo(lx1m,ly1m,lz1m,lelt), $ wzo(lx1m,ly1m,lz1m,lelt) $ , WXLAGo (LX1M,LY1M,LZ1M,LELT,LORDER-1) $ , WYLAGo (LX1M,LY1M,LZ1M,LELT,LORDER-1) $ , WZLAGo (LX1M,LY1M,LZ1M,LELT,LORDER-1) $ , W1MASKo(LX1M,LY1M,LZ1M,LELT) $ , W2MASKo(LX1M,LY1M,LZ1M,LELT) $ , W3MASKo(LX1M,LY1M,LZ1M,LELT) $ , WMULTo (LX1M,LY1M,LZ1M,LELT) real alpha real tollit real errvc integer npcyl if (istep.eq.0) then call findcyl(indcyl) endif scale=1. call evalYcyl write(6,*) "ycyl=",ycyl n=lx1*ly1*lz1*lelv npre=lx2*ly2*lz2*lelv if (istep.eq.10) then call copy_step endif if(istep.eq.20) then call load_step endif call torque_calc(scale,x0,.true.,.false.) return end c ------------------------------------------------------------------------- subroutine copy_step include 'SIZE' include 'TOTAL' include 'RESTART' common /indici/ indcyl(lx1,ly1,lz1,lelv) common /contatori/ icont,istepold,timeold,firstit integer icont, istepold,n,npre,firstit common /olddati/ vxo(lx1,ly1,lz1,lelv),vyo(lx1,ly1,lz1,lelv), $ vzo(lx1,ly1,lz1,lelv),xm1o(lx1,ly1,lz1,lelv), $ ym1o(lx1,ly1,lz1,lelv),zm1o(lx1,ly1,lz1,lelv), $ vxlago(lx1,ly1,lz1,lelv,2),vylago(lx1,ly1,lz1,lelv,2), $ vzlago(lx1,ly1,lz1,lelv,2) $ , ABX1o (LX1,LY1,LZ1,LELV) $ , ABY1o (LX1,LY1,LZ1,LELV) $ , ABZ1o (LX1,LY1,LZ1,LELV) $ , ABX2o (LX1,LY1,LZ1,LELV) $ , ABY2o (LX1,LY1,LZ1,LELV) $ , ABZ2o (LX1,LY1,LZ1,LELV) $ , PRLAGo (LX2,LY2,LZ2,LELV,LORDER2),pro(lx2,ly2,lz2,lelv) $ , wxo(lx1m,ly1m,lz1m,lelt),wyo(lx1m,ly1m,lz1m,lelt), $ wzo(lx1m,ly1m,lz1m,lelt) $ , WXLAGo (LX1M,LY1M,LZ1M,LELT,LORDER-1) $ , WYLAGo (LX1M,LY1M,LZ1M,LELT,LORDER-1) $ , WZLAGo (LX1M,LY1M,LZ1M,LELT,LORDER-1) $ , W1MASKo(LX1M,LY1M,LZ1M,LELT) $ , W2MASKo(LX1M,LY1M,LZ1M,LELT) $ , W3MASKo(LX1M,LY1M,LZ1M,LELT) $ , WMULTo (LX1M,LY1M,LZ1M,LELT), fyold n=lx1*ly1*lz1*lelv npre=lx2*ly2*lz2*lelv call opcopy(vxo,vyo,vzo,vx,vy,vz) call opcopy(wxo,wyo,wzo,wx,wy,wz) do i=1,lorder-1 call opcopy(vxlago(1,1,1,1,i),vylago(1,1,1,1,i), $ vzlago(1,1,1,1,i),vxlag(1,1,1,1,i),vylag(1,1,1,1,i), $ vzlag(1,1,1,1,i)) call opcopy(wxlago(1,1,1,1,i),wylago(1,1,1,1,i), $ wzlago(1,1,1,1,i),wxlag(1,1,1,1,i),wylag(1,1,1,1,i), $ wzlag(1,1,1,1,i)) enddo call copy(w1masko,w1mask,n) call copy(w2masko,w2mask,n) call copy(w3masko,w3mask,n) call copy(wmulto,wmult,n) call copy(abx1o,abx1,n) call copy(aby1o,aby1,n) call copy(abz1o,abz1,n) call copy(abx2o,abx2,n) call copy(aby2o,aby2,n) call copy(abz2o,abz2,n) do i=1,lorder2 call copy(prlago(1,1,1,1,i),prlag(1,1,1,1,i),npre) enddo call copy(pro,pr,npre) call opcopy(xm1o,ym1o,zm1o,xm1,ym1,zm1) return end c-------------------------------------------- subroutine load_step include 'SIZE' include 'TOTAL' include 'RESTART' parameter (lt=lx1*ly1*lz1*lelv) common /indici/ indcyl(lx1,ly1,lz1,lelv) common /contatori/ icont,istepold,timeold,firstit integer icont, istepold,n,npre,firstit common /olddati/ vxo(lx1,ly1,lz1,lelv),vyo(lx1,ly1,lz1,lelv), $ vzo(lx1,ly1,lz1,lelv),xm1o(lx1,ly1,lz1,lelv), $ ym1o(lx1,ly1,lz1,lelv),zm1o(lx1,ly1,lz1,lelv), $ vxlago(lx1,ly1,lz1,lelv,2),vylago(lx1,ly1,lz1,lelv,2), $ vzlago(lx1,ly1,lz1,lelv,2) $ , ABX1o (LX1,LY1,LZ1,LELV) $ , ABY1o (LX1,LY1,LZ1,LELV) $ , ABZ1o (LX1,LY1,LZ1,LELV) $ , ABX2o (LX1,LY1,LZ1,LELV) $ , ABY2o (LX1,LY1,LZ1,LELV) $ , ABZ2o (LX1,LY1,LZ1,LELV) $ , PRLAGo (LX2,LY2,LZ2,LELV,LORDER2),pro(lx2,ly2,lz2,lelv) $ , wxo(lx1m,ly1m,lz1m,lelt),wyo(lx1m,ly1m,lz1m,lelt), $ wzo(lx1m,ly1m,lz1m,lelt) $ , WXLAGo (LX1M,LY1M,LZ1M,LELT,LORDER-1) $ , WYLAGo (LX1M,LY1M,LZ1M,LELT,LORDER-1) $ , WZLAGo (LX1M,LY1M,LZ1M,LELT,LORDER-1) $ , W1MASKo(LX1M,LY1M,LZ1M,LELT) $ , W2MASKo(LX1M,LY1M,LZ1M,LELT) $ , W3MASKo(LX1M,LY1M,LZ1M,LELT) $ , WMULTo (LX1M,LY1M,LZ1M,LELT), fyold n=lx1*ly1*lz1*lelv npre=lx2*ly2*lz2*lelv call opcopy(vx,vy,vz,vxo,vyo,vzo) call opcopy(wx,wy,wz,wxo,wyo,wzo) do i=1,lorder-1 call opcopy(vxlag(1,1,1,1,i),vylag(1,1,1,1,i), $ vzlag(1,1,1,1,i),vxlago(1,1,1,1,i),vylago(1,1,1,1,i), $ vzlago(1,1,1,1,i)) call opcopy(wxlag(1,1,1,1,i),wylag(1,1,1,1,i), $ wzlag(1,1,1,1,i),wxlago(1,1,1,1,i),wylago(1,1,1,1,i), $ wzlago(1,1,1,1,i)) enddo call copy(abz1,abz1o,n) call copy(abx1,abx1o,n) call copy(aby1,aby1o,n) call copy(abz1,abz1o,n) call copy(abx2,abx2o,n) call copy(aby2,aby2o,n) call copy(abz2,abz2o,n) call copy(w1mask,w1masko,n) call copy(w2mask,w2masko,n) call copy(w3mask,w3masko,n) call copy(wmult,wmulto,n) do i=1,lorder2 call copy(prlag(1,1,1,1,i),prlago(1,1,1,1,i),npre) enddo call copy(pr,pro,npre) call opcopy(xm1,ym1,zm1,xm1o,ym1o,zm1o) call geom_reset(1) call setup_convect(1) call setup_convect(2) c call setup_convect(3) return end _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users From nek5000-users at lists.mcs.anl.gov Tue Jun 25 03:05:17 2013 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 25 Jun 2013 10:05:17 +0200 Subject: [Nek5000-users] Full restart during a simulation Message-ID: Dear Paul, thanks for your help. Copyng bm1lag does the trick, now the procedure works. Andrea -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Tue Jun 25 04:24:14 2013 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 25 Jun 2013 02:24:14 -0700 Subject: [Nek5000-users] Writing 2d output files for 3d data Message-ID: We are generating huge 3d data files (>8GB with multiple I/O) which are so large, our version of visit does not have enough memory to load them. Oftentimes we only want to visualize a 2d slice anyway. Is there a routine in nek5000 that does this? Or one that can be easily modified? To be more specific, we want to output, for example, the coordinates and the velocity field for some fixed z-value, into a blah.f00001 file that can then be read by visit. Thanks, Janet -- Janet Scheel Assistant Professor of Physics Occidental College 1600 Campus Road, M21 Los Angeles, CA 90041 (323) 259-2777 jscheel at oxy.edu -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Tue Jun 25 06:28:09 2013 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 25 Jun 2013 06:28:09 -0500 (CDT) Subject: [Nek5000-users] Writing 2d output files for 3d data In-Reply-To: References: Message-ID: Hi Janet, I think that z_slice() and outfld2d would be reasonable starting points. As I look at the code, z_slice takes element 1, slice 1 in the z direction. You would want to generalize this. Also, it looks outfld2d() is set up only for ascii output at the moment. I would suggest conversion to binary. I can take a pass at making these changes but will not have time to verify functionality for a few days. I could however work with you on that. Paul On Tue, 25 Jun 2013, nek5000-users at lists.mcs.anl.gov wrote: > We are generating huge 3d data files (>8GB with multiple I/O) which are so > large, our version of visit does not have enough memory to load them. > Oftentimes we only want to visualize a 2d slice anyway. Is there a routine > in nek5000 that does this? Or one that can be easily modified? To be more > specific, we want to output, for example, the coordinates and the velocity > field for some fixed z-value, into a blah.f00001 file that can then be read > by visit. > > Thanks, > > Janet > > -- > Janet Scheel > Assistant Professor of Physics > Occidental College > 1600 Campus Road, M21 > Los Angeles, CA 90041 > (323) 259-2777 > jscheel at oxy.edu > From nek5000-users at lists.mcs.anl.gov Tue Jun 25 07:00:06 2013 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 25 Jun 2013 07:00:06 -0500 (CDT) Subject: [Nek5000-users] Writing 2d output files for 3d data In-Reply-To: References: Message-ID: Hi Janet, I added z_slice_g, a generalized z_slice() extraction routine to the repo in navier5.f. I've not tested it. Please let me know if this works for you. Note that all it does is to extract a scalar. You would call this once for each variable of interest and then dump them as a field using some type of output routine --- outfld2d() and outfld2d_p() look like decent starting points but are not quite what you need. If I were you, I would start with the binary .fld (not .f0000) format from a single processor and see how long that takes. I think the _p() variant does the following --- For several processors, it holds the data from different output times (e.g., proc 0 holds time 1, proc 64 holds time 2, etc.). Then, at an agreed-upon timestep, each of these opens a file, in parallel, and writes the entire z-slice that it holds as a copy. Since each processor gets an entire z-slice from the above routine, this is not a big deal, and you still get parallel I/O --- it's time parallel instead of space parallel. Here's a cartoon: time/space: p0 p4 p12 p16 step 1000 get slice get slice get slice get slice step 1000 save slice step 2000 get slice get slice get slice get slice step 2000 save slice step 3000 get slice get slice get slice get slice step 3000 save slice step 4000 get slice get slice get slice get slice step 4000 save slice step 4000 write f1 write f2 write f3 write f4 <-- Parallel IO The attraction of this approach is that the write() looks like serial I/O because the requisite data is fully resident on the processor that is doing the write, so it is simpler to code. Paul On Tue, 25 Jun 2013, nek5000-users at lists.mcs.anl.gov wrote: > > Hi Janet, > > I think that z_slice() and outfld2d would be reasonable > starting points. > > As I look at the code, z_slice takes element 1, slice 1 > in the z direction. You would want to generalize this. > > Also, it looks outfld2d() is set up only for ascii output > at the moment. I would suggest conversion to binary. > > I can take a pass at making these changes but will not have > time to verify functionality for a few days. I could however > work with you on that. > > Paul > > > On Tue, 25 Jun 2013, nek5000-users at lists.mcs.anl.gov wrote: > >> We are generating huge 3d data files (>8GB with multiple I/O) which are so >> large, our version of visit does not have enough memory to load them. >> Oftentimes we only want to visualize a 2d slice anyway. Is there a routine >> in nek5000 that does this? Or one that can be easily modified? To be more >> specific, we want to output, for example, the coordinates and the velocity >> field for some fixed z-value, into a blah.f00001 file that can then be read >> by visit. >> >> Thanks, >> >> Janet >> >> -- >> Janet Scheel >> Assistant Professor of Physics >> Occidental College >> 1600 Campus Road, M21 >> Los Angeles, CA 90041 >> (323) 259-2777 >> jscheel at oxy.edu >> > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > From nek5000-users at lists.mcs.anl.gov Tue Jun 25 10:16:37 2013 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 25 Jun 2013 08:16:37 -0700 Subject: [Nek5000-users] Writing 2d output files for 3d data In-Reply-To: References: Message-ID: Paul, Thanks for the starting points. I have a few more questions, especially about the parallelization that's necessary for these huge systems. I don't really care about speed here, I just want to output a 2d slice and I don't plan on doing it very often. 1.) for z_slice_g(), what is ezi? Say I want to output all the data at z=0 (i.e. the bottom plate). What would I use for ezi? Or do I have to create some routine to find ezi for this case? 2.) I am a little confused about the parallel version of outfld2d(). It looks like outfld2d_p gets called by buff_2d_out(). Would you suggest doing this? Thanks, Janet > Hi Janet, > > I added z_slice_g, a generalized z_slice() extraction routine > to the repo in navier5.f. > > I've not tested it. > > Please let me know if this works for you. Note that all it > does is to extract a scalar. You would call this once for each > variable of interest and then dump them as a field using some > type of output routine --- outfld2d() and outfld2d_p() look > like decent starting points but are not quite what you need. > > If I were you, I would start with the binary .fld (not .f0000) > format from a single processor and see how long that takes. > > I think the _p() variant does the following --- > > For several processors, it holds the data from different output > times (e.g., proc 0 holds time 1, proc 64 holds time 2, etc.). > Then, at an agreed-upon timestep, each of these opens a file, > in parallel, and writes the entire z-slice that it holds as a copy. > > Since each processor gets an entire z-slice from the above routine, > this is not a big deal, and you still get parallel I/O --- it's > time parallel instead of space parallel. Here's a cartoon: > > > time/space: p0 p4 p12 p16 > > step 1000 get slice get slice get slice get slice > step 1000 save slice > > step 2000 get slice get slice get slice get slice > step 2000 save slice > > step 3000 get slice get slice get slice get slice > step 3000 save slice > > step 4000 get slice get slice get slice get slice > step 4000 save slice > > step 4000 write f1 write f2 write f3 write f4 <-- Parallel IO > > The attraction of this approach is that the write() looks > like serial I/O because the requisite data is fully resident > on the processor that is doing the write, so it is simpler > to code. > > > Paul > > On Tue, 25 Jun 2013, nek5000-users at lists.mcs.anl.gov wrote: > > > Hi Janet, > > > I think that z_slice() and outfld2d would be reasonable > > starting points. > > > As I look at the code, z_slice takes element 1, slice 1 > > in the z direction. You would want to generalize this. > > > Also, it looks outfld2d() is set up only for ascii output > > at the moment. I would suggest conversion to binary. > > > I can take a pass at making these changes but will not have > > time to verify functionality for a few days. I could however > > work with you on that. > > > Paul > > > > On Tue, 25 Jun 2013, nek5000-users at lists.mcs.anl.gov wrote: > > > We are generating huge 3d data files (>8GB with multiple I/O) which are so > > large, our version of visit does not have enough memory to load them. > > Oftentimes we only want to visualize a 2d slice anyway. Is there a routine > > in nek5000 that does this? Or one that can be easily modified? To be more > > specific, we want to output, for example, the coordinates and the velocity > > field for some fixed z-value, into a blah.f00001 file that can then be read > > by visit. > > Thanks, > > Janet > > -- > > Janet Scheel > > Assistant Professor of Physics > > Occidental College > > 1600 Campus Road, M21 > > Los Angeles, CA 90041 > > (323) 259-2777 > > jscheel at oxy.edu > > _______________________________________________ > > Nek5000-users mailing list > > Nek5000-users at lists.mcs.anl.gov > > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > > -- Janet Scheel Assistant Professor of Physics Occidental College 1600 Campus Road, M21 Los Angeles, CA 90041 (323) 259-2777 jscheel at oxy.edu -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Tue Jun 25 10:37:24 2013 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 25 Jun 2013 17:37:24 +0200 Subject: [Nek5000-users] Writing 2d output files for 3d data In-Reply-To: Message-ID: I think there are two ways to approach this problem: - Discover why you run out of memory with VisIt? Is this to be expected? How many elements and what polynomial order are you using? How much memory memory does your machine have? Which VisIt version are you using? May be VisIt is running into a memory leak? - Let's assume you can't do it with VisIt (for whatever reason). I guess one option you may want to consider is: Get the data for a defined set of points (e.g slice grid) using the parallel interpolation routines and dump the data into a single or shared (MPI-IO) file. Make sure that your file format is supported by VisIt. This works really well even with huge data sets. Hth, Stefan Von: Antworten an: Datum: Tue, 25 Jun 2013 08:16:37 -0700 An: Betreff: Re: [Nek5000-users] Writing 2d output files for 3d data Paul, Thanks for the starting points. I have a few more questions, especially about the parallelization that's necessary for these huge systems. I don't really care about speed here, I just want to output a 2d slice and I don't plan on doing it very often. 1.) for z_slice_g(), what is ezi? Say I want to output all the data at z=0 (i.e. the bottom plate). What would I use for ezi? Or do I have to create some routine to find ezi for this case? 2.) I am a little confused about the parallel version of outfld2d(). It looks like outfld2d_p gets called by buff_2d_out(). Would you suggest doing this? Thanks, Janet >> >> Hi Janet, >> >> I added z_slice_g, a generalized z_slice() extraction routine >> to the repo in navier5.f. >> >> I've not tested it. >> >> Please let me know if this works for you. Note that all it >> does is to extract a scalar. You would call this once for each >> variable of interest and then dump them as a field using some >> type of output routine --- outfld2d() and outfld2d_p() look >> like decent starting points but are not quite what you need. >> >> If I were you, I would start with the binary .fld (not .f0000) >> format from a single processor and see how long that takes. >> >> I think the _p() variant does the following --- >> >> For several processors, it holds the data from different output >> times (e.g., proc 0 holds time 1, proc 64 holds time 2, etc.). >> Then, at an agreed-upon timestep, each of these opens a file, >> in parallel, and writes the entire z-slice that it holds as a copy. >> >> Since each processor gets an entire z-slice from the above routine, >> this is not a big deal, and you still get parallel I/O --- it's >> time parallel instead of space parallel. Here's a cartoon: >> >> >> time/space: p0 p4 p12 p16 >> >> step 1000 get slice get slice get slice get slice >> step 1000 save slice >> >> step 2000 get slice get slice get slice get slice >> step 2000 save slice >> >> step 3000 get slice get slice get slice get slice >> step 3000 save slice >> >> step 4000 get slice get slice get slice get slice >> step 4000 save slice >> >> step 4000 write f1 write f2 write f3 write f4 <-- Parallel IO >> >> The attraction of this approach is that the write() looks >> like serial I/O because the requisite data is fully resident >> on the processor that is doing the write, so it is simpler >> to code. >> >> >> Paul >> >> On Tue, 25 Jun 2013, nek5000-users at lists.mcs.anl.gov wrote: >> >>> >>> Hi Janet, >>> >>> I think that z_slice() and outfld2d would be reasonable >>> starting points. >>> >>> As I look at the code, z_slice takes element 1, slice 1 >>> in the z direction. You would want to generalize this. >>> >>> Also, it looks outfld2d() is set up only for ascii output >>> at the moment. I would suggest conversion to binary. >>> >>> I can take a pass at making these changes but will not have >>> time to verify functionality for a few days. I could however >>> work with you on that. >>> >>> Paul >>> >>> >>> On Tue, 25 Jun 2013, nek5000-users at lists.mcs.anl.gov wrote: >>> >>>> We are generating huge 3d data files (>8GB with multiple I/O) which are so >>>> large, our version of visit does not have enough memory to load them. >>>> Oftentimes we only want to visualize a 2d slice anyway. Is there a routine >>>> in nek5000 that does this? Or one that can be easily modified? To be more >>>> specific, we want to output, for example, the coordinates and the velocity >>>> field for some fixed z-value, into a blah.f00001 file that can then be read >>>> by visit. >>>> Thanks, >>>> Janet >>>> -- >>>> Janet Scheel >>>> Assistant Professor of Physics >>>> Occidental College >>>> 1600 Campus Road, M21 >>>> Los Angeles, CA 90041 >>>> (323) 259-2777 >>>> jscheel at oxy.edu >>> _______________________________________________ >>> Nek5000-users mailing list >>> Nek5000-users at lists.mcs.anl.gov >>> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >>> >> _______________________________________________ >> Nek5000-users mailing list >> Nek5000-users at lists.mcs.anl.gov >> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > -- Janet Scheel Assistant Professor of Physics Occidental College 1600 Campus Road, M21 Los Angeles, CA 90041 (323) 259-2777 jscheel at oxy.edu _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Tue Jun 25 11:10:43 2013 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Tue, 25 Jun 2013 18:10:43 +0200 Subject: [Nek5000-users] Writing 2d output files for 3d data In-Reply-To: Message-ID: I can think of another option: Just run nek in post-processsing mode and use the grid-to-grid interpolation tool to get the data interpolated on a slab. As an input for g2gi() a 3D slab fld-file is needed. Stefan Von: Antworten an: Datum: Tue, 25 Jun 2013 17:37:24 +0200 An: Betreff: Re: [Nek5000-users] Writing 2d output files for 3d data I think there are two ways to approach this problem: - Discover why you run out of memory with VisIt? Is this to be expected? How many elements and what polynomial order are you using? How much memory memory does your machine have? Which VisIt version are you using? May be VisIt is running into a memory leak? - Let's assume you can't do it with VisIt (for whatever reason). I guess one option you may want to consider is: Get the data for a defined set of points (e.g slice grid) using the parallel interpolation routines and dump the data into a single or shared (MPI-IO) file. Make sure that your file format is supported by VisIt. This works really well even with huge data sets. Hth, Stefan Von: Antworten an: Datum: Tue, 25 Jun 2013 08:16:37 -0700 An: Betreff: Re: [Nek5000-users] Writing 2d output files for 3d data Paul, Thanks for the starting points. I have a few more questions, especially about the parallelization that's necessary for these huge systems. I don't really care about speed here, I just want to output a 2d slice and I don't plan on doing it very often. 1.) for z_slice_g(), what is ezi? Say I want to output all the data at z=0 (i.e. the bottom plate). What would I use for ezi? Or do I have to create some routine to find ezi for this case? 2.) I am a little confused about the parallel version of outfld2d(). It looks like outfld2d_p gets called by buff_2d_out(). Would you suggest doing this? Thanks, Janet >> >> Hi Janet, >> >> I added z_slice_g, a generalized z_slice() extraction routine >> to the repo in navier5.f. >> >> I've not tested it. >> >> Please let me know if this works for you. Note that all it >> does is to extract a scalar. You would call this once for each >> variable of interest and then dump them as a field using some >> type of output routine --- outfld2d() and outfld2d_p() look >> like decent starting points but are not quite what you need. >> >> If I were you, I would start with the binary .fld (not .f0000) >> format from a single processor and see how long that takes. >> >> I think the _p() variant does the following --- >> >> For several processors, it holds the data from different output >> times (e.g., proc 0 holds time 1, proc 64 holds time 2, etc.). >> Then, at an agreed-upon timestep, each of these opens a file, >> in parallel, and writes the entire z-slice that it holds as a copy. >> >> Since each processor gets an entire z-slice from the above routine, >> this is not a big deal, and you still get parallel I/O --- it's >> time parallel instead of space parallel. Here's a cartoon: >> >> >> time/space: p0 p4 p12 p16 >> >> step 1000 get slice get slice get slice get slice >> step 1000 save slice >> >> step 2000 get slice get slice get slice get slice >> step 2000 save slice >> >> step 3000 get slice get slice get slice get slice >> step 3000 save slice >> >> step 4000 get slice get slice get slice get slice >> step 4000 save slice >> >> step 4000 write f1 write f2 write f3 write f4 <-- Parallel IO >> >> The attraction of this approach is that the write() looks >> like serial I/O because the requisite data is fully resident >> on the processor that is doing the write, so it is simpler >> to code. >> >> >> Paul >> >> On Tue, 25 Jun 2013, nek5000-users at lists.mcs.anl.gov wrote: >> >>> >>> Hi Janet, >>> >>> I think that z_slice() and outfld2d would be reasonable >>> starting points. >>> >>> As I look at the code, z_slice takes element 1, slice 1 >>> in the z direction. You would want to generalize this. >>> >>> Also, it looks outfld2d() is set up only for ascii output >>> at the moment. I would suggest conversion to binary. >>> >>> I can take a pass at making these changes but will not have >>> time to verify functionality for a few days. I could however >>> work with you on that. >>> >>> Paul >>> >>> >>> On Tue, 25 Jun 2013, nek5000-users at lists.mcs.anl.gov wrote: >>> >>>> We are generating huge 3d data files (>8GB with multiple I/O) which are so >>>> large, our version of visit does not have enough memory to load them. >>>> Oftentimes we only want to visualize a 2d slice anyway. Is there a routine >>>> in nek5000 that does this? Or one that can be easily modified? To be more >>>> specific, we want to output, for example, the coordinates and the velocity >>>> field for some fixed z-value, into a blah.f00001 file that can then be read >>>> by visit. >>>> Thanks, >>>> Janet >>>> -- >>>> Janet Scheel >>>> Assistant Professor of Physics >>>> Occidental College >>>> 1600 Campus Road, M21 >>>> Los Angeles, CA 90041 >>>> (323) 259-2777 >>>> jscheel at oxy.edu >>> _______________________________________________ >>> Nek5000-users mailing list >>> Nek5000-users at lists.mcs.anl.gov >>> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users >>> >> _______________________________________________ >> Nek5000-users mailing list >> Nek5000-users at lists.mcs.anl.gov >> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > -- Janet Scheel Assistant Professor of Physics Occidental College 1600 Campus Road, M21 Los Angeles, CA 90041 (323) 259-2777 jscheel at oxy.edu _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.govhttps://lists.mcs.anl.gov/mailman/listinfo/ne k5000-users _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Wed Jun 26 08:22:17 2013 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 26 Jun 2013 15:22:17 +0200 Subject: [Nek5000-users] genmap, ABORT: SELF-CHK In-Reply-To: References: Message-ID: Hi Neks, Frank, did you ever find the solution to this error? I have the same problem. Thank you for your help, Holly Johnson Masters Student at ONERA - DAFE D?partement d'A?ronautique Fondamentale et Exp?rimentale 8, Rue des Vertugadins 92190 - Meudon - France On Apr 29, 2010, at 5:23 PM,nek5000-users at lists.mcs.anl.gov wrote: />Hello all, > >I am running into a problem with "genmap", see error below. My *.rea >file that I feed to "genmap" is: >http://tetra.fluid.tuwien.ac.at/fmuldoo/engineering-marangoni-flows/sim2/sim1/sim1/sim11/openboat3D.rea > >[root at frank sim11]# genmap >Input (.rea) file name: >openboat3D >Input mesh tolerance (default 0.2): >NOTE: smaller is better, but generous is more forgiving for bad meshes. >.2 > reading .rea file data ... > start locglob_lexico: 8 1 8 >0.200000000000000 > locglob: 1 1 8 > locglob: 2 2 8 > locglob: 3 4 8 > locglob: 1 8 8 > locglob: 2 8 8 > locglob: 3 8 8 > locglob: 1 8 8 > locglob: 2 8 8 > locglob: 3 8 8 > done locglob_lexico: 8 8 8 1 > start periodic vtx: 1 8 > 1 5 5 3 0.00000000E+00 1 shift > 1 6 5 3 0.00000000E+00 2 shift > > 1 2 4 Matrix: SELF!! > 1 SELF!! 1 2 1 2 > 2 SELF!! 3 4 3 4 > > ABORT: SELF-CHK 1 5 1 6 > Try to tighten the mesh tolerance! > > 6 quit > >Cheers, >Frank > >-- >Frank Herbert Muldoon, Ph.D. Mechanical Engineering >Technische Universit?t Wien (Technical University of Vienna) >Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid >Mechanics and Heat Transfer) >Resselgasse 3 >1040 Wien >Tel: +4315880132232 >Fax: +4315880132299 >Cell:+436765203470 >fmuldoo (skype) >http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Wed Jun 26 08:38:43 2013 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 26 Jun 2013 08:38:43 -0500 (CDT) Subject: [Nek5000-users] genmap, ABORT: SELF-CHK In-Reply-To: References: Message-ID: Hi Holly, To the best of my knowledge, we solved this problem for Frank. The error usually indicates a problem with the mesh. If you'd like, email me off-list (fischer at mcs.anl.gov) and we can figure out a way to get your mesh to me - email, if it's small enough - and I can take a look. Paul On Wed, 26 Jun 2013, nek5000-users at lists.mcs.anl.gov wrote: > Hi Neks, > > Frank, did you ever find the solution to this error? I have the same problem. > > Thank you for your help, > > Holly Johnson > > Masters Student at ONERA - DAFE > D?partement d'A?ronautique Fondamentale et Exp?rimentale > 8, Rue des Vertugadins > 92190 - Meudon - France > > On Apr 29, 2010, at 5:23 PM,nek5000-users at lists.mcs.anl.gov > wrote: > > />Hello all, >> >> I am running into a problem with "genmap", see error below. My *.rea >> file that I feed to "genmap" is: >> http://tetra.fluid.tuwien.ac.at/fmuldoo/engineering-marangoni-flows/sim2/sim1/sim1/sim11/openboat3D.rea >> >> [root at frank >> sim11]# genmap >> Input (.rea) file name: >> openboat3D >> Input mesh tolerance (default 0.2): >> NOTE: smaller is better, but generous is more forgiving for bad meshes. >> .2 >> reading .rea file data ... >> start locglob_lexico: 8 1 8 >> 0.200000000000000 >> locglob: 1 1 8 >> locglob: 2 2 8 >> locglob: 3 4 8 >> locglob: 1 8 8 >> locglob: 2 8 8 >> locglob: 3 8 8 >> locglob: 1 8 8 >> locglob: 2 8 8 >> locglob: 3 8 8 >> done locglob_lexico: 8 8 8 1 >> start periodic vtx: 1 8 >> 1 5 5 3 0.00000000E+00 1 shift >> 1 6 5 3 0.00000000E+00 2 shift >> >> 1 2 4 Matrix: SELF!! >> 1 SELF!! 1 2 1 2 >> 2 SELF!! 3 4 3 4 >> >> ABORT: SELF-CHK 1 5 1 6 >> Try to tighten the mesh tolerance! >> >> 6 quit >> >> Cheers, >> Frank >> >> -- >> Frank Herbert Muldoon, Ph.D. Mechanical Engineering >> Technische Universit?t Wien (Technical University of Vienna) >> Inst. f. Str?mungsmechanik und W?rme?bertragung (Institute of Fluid >> Mechanics and Heat Transfer) >> Resselgasse 3 >> 1040 Wien >> Tel: +4315880132232 >> Fax: +4315880132299 >> Cell:+436765203470 >> fmuldoo (skype) >> http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html/ > > From nek5000-users at lists.mcs.anl.gov Wed Jun 26 09:54:38 2013 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 26 Jun 2013 09:54:38 -0500 (CDT) Subject: [Nek5000-users] Problem with Genmap In-Reply-To: <51CAFA4D.2050608@onera.fr> References: <51CAFA4D.2050608@onera.fr> Message-ID: Hi Holly, I've posted this back to the list since it doesn't involve big data files and the resolution of the problem might be of interest to others. I think I see what's going on and have a couple ideas to fix it. Most likely, the reduction attained with 50 elements and a geomtric progression of 0.7 is wreaking havoc either in the .rea file or in the tolerances within genmap. A significant issue here is that the file format in the .rea file is in limited precision --- I think we can change that with little difficulty and still be compatible with the workflow. We'll look into that on our end. A reasonable work-around, which is what I typically do, would be to rescale your element coordinates inside nek, and just use a uniform mesh as the input. I'll send along some code on how to do this shortly --- along with another approach that will also give you focused resolution at the origin without the high aspect ratio elements that will result from the tensor-product approach used here. Paul On Wed, 26 Jun 2013, Holly Johnson wrote: > Hi Paul, > > My mesh is actually quite simple, I've had to reduce it from a much more > complicated version because Visit couldn't handle the number of elements I > was using. > > This is my .box file : > > linear.rea > 2 > 1 > # > # linear.box > # > Box > -50 -50 > -3. 0. 0.7 > -3. 0. 0.7 > SYM, ,v , > Box > -50 -50 > -3. 0. 0.7 > 0. 3. 1.3 > SYM, , ,O > Box > -50 -50 > 0. 3. 1.3 > -3. 0. 0.7 > ,SYM,v , > Box > -50 -50 > 0. 3. 1.3 > 0. 3. 1.3 > ,SYM, ,O > > I get the error for any mesh tolerance value when the scaling coefficients > are _<_ 0.7 or _>_ 1.3. However it works fine for _>_0.8 and _<_1.2. I assume > therefore it is that the elements of the mesh near the center of the grid are > just too small? > > Thanks again for your help, > > Holly > > Holly Johnson > Masters Student at ONERA - DAFE > D?partement d'A?rodynamique Fondamentale et Exp?rimentale > 8, Rue des Vertugadins > 92190 - Meudon - France > > From nek5000-users at lists.mcs.anl.gov Wed Jun 26 14:28:44 2013 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 26 Jun 2013 14:28:44 -0500 Subject: [Nek5000-users] Problem with Genmap In-Reply-To: References: <51CAFA4D.2050608@onera.fr> Message-ID: Hi, It turns out the problem was with the genbox tool. I have updated the makefile in trunk/tools to compile genbox in double precision. This should take care of the problem and genmap should work as expected. Be sure to do a clean recompile of genbox to enact the update. Best, Katie On Wed, Jun 26, 2013 at 9:54 AM, wrote: > > Hi Holly, > > I've posted this back to the list since it doesn't involve big > data files and the resolution of the problem might be of interest > to others. > > I think I see what's going on and have a couple ideas to fix it. > > Most likely, the reduction attained with 50 elements and a geomtric > progression of 0.7 is wreaking havoc either in the .rea file or in > the tolerances within genmap. A significant issue here is that > the file format in the .rea file is in limited precision --- I think > we can change that with little difficulty and still be compatible > with the workflow. We'll look into that on our end. > > A reasonable work-around, which is what I typically do, would be > to rescale your element coordinates inside nek, and just use a uniform > mesh as the input. I'll send along some code on how to > do this shortly --- along with another approach that will also > give you focused resolution at the origin without the high aspect > ratio elements that will result from the tensor-product approach > used here. > > Paul > > > > On Wed, 26 Jun 2013, Holly Johnson wrote: > > Hi Paul, >> >> My mesh is actually quite simple, I've had to reduce it from a much more >> complicated version because Visit couldn't handle the number of elements I >> was using. >> >> This is my .box file : >> >> linear.rea >> 2 >> 1 >> # >> # linear.box >> # >> Box >> -50 -50 >> -3. 0. 0.7 >> -3. 0. 0.7 >> SYM, ,v , >> Box >> -50 -50 >> -3. 0. 0.7 >> 0. 3. 1.3 >> SYM, , ,O >> Box >> -50 -50 >> 0. 3. 1.3 >> -3. 0. 0.7 >> ,SYM,v , >> Box >> -50 -50 >> 0. 3. 1.3 >> 0. 3. 1.3 >> ,SYM, ,O >> >> I get the error for any mesh tolerance value when the scaling >> coefficients are _<_ 0.7 or _>_ 1.3. However it works fine for _>_0.8 and >> _<_1.2. I assume therefore it is that the elements of the mesh near the >> center of the grid are just too small? >> >> Thanks again for your help, >> >> Holly >> >> Holly Johnson >> Masters Student at ONERA - DAFE >> D?partement d'A?rodynamique Fondamentale et Exp?rimentale >> 8, Rue des Vertugadins >> 92190 - Meudon - France >> >> > _______________________________________________ > Nek5000-users mailing list > Nek5000-users at lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Wed Jun 26 15:14:54 2013 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 26 Jun 2013 15:14:54 -0500 (CDT) Subject: [Nek5000-users] Problem with Genmap In-Reply-To: References: <51CAFA4D.2050608@onera.fr> Message-ID: Hi Holly, Attached is a tarfile with a script "mkmesh" and a .usr file that will take a regular square grid and compress it near the center. Compression has two components: 1) a tensor-product compression, similar to what you had 2) a pseudo-orthogonal grid concentration The purpose of the second part is to avoid very high aspect ratio cells, which really impact the conditioning of the linear systems and consequently the iteration counts. On this latter point, let me make a couple of comments/questions. In your original script you had a compression factor of 0.7, extended over 50 elements, which would give a largest to smallest ratio of ~ 1.e-8 and you would end up with an aspect ratio of approximately 1.e-6. My guess is that you have something very near the origin that you are trying to resolve and are not interested in the far field. Because of the difficulties with high-aspect ratio elements (which is common to all discretizations, but see pp. 24-26 of www.mcs.anl.gov/~fischer/pubhtml/jcp97.pdf for a discussion related to the SEM), it might be of interest to consider an O-grid, i.e., a cylinder, in which you can easily focus resolution and maintain near unit aspect-ratio throughout the domain. Attached is an example mesh (in t.t2.gz). I can also provide the scripts used to generate this, if of interest. Paul On Wed, 26 Jun 2013, nek5000-users at lists.mcs.anl.gov wrote: > > Hi Holly, > > I've posted this back to the list since it doesn't involve big > data files and the resolution of the problem might be of interest > to others. > > I think I see what's going on and have a couple ideas to fix it. > > Most likely, the reduction attained with 50 elements and a geomtric > progression of 0.7 is wreaking havoc either in the .rea file or in > the tolerances within genmap. A significant issue here is that > the file format in the .rea file is in limited precision --- I think > we can change that with little difficulty and still be compatible > with the workflow. We'll look into that on our end. > > A reasonable work-around, which is what I typically do, would be > to rescale your element coordinates inside nek, and just use a uniform mesh > as the input. I'll send along some code on how to > do this shortly --- along with another approach that will also > give you focused resolution at the origin without the high aspect > ratio elements that will result from the tensor-product approach > used here. > > Paul > > > > On Wed, 26 Jun 2013, Holly Johnson wrote: > >> Hi Paul, >> >> My mesh is actually quite simple, I've had to reduce it from a much more >> complicated version because Visit couldn't handle the number of elements I >> was using. >> >> This is my .box file : >> >> linear.rea >> 2 >> 1 >> # >> # linear.box >> # >> Box >> -50 -50 >> -3. 0. 0.7 >> -3. 0. 0.7 >> SYM, ,v , >> Box >> -50 -50 >> -3. 0. 0.7 >> 0. 3. 1.3 >> SYM, , ,O >> Box >> -50 -50 >> 0. 3. 1.3 >> -3. 0. 0.7 >> ,SYM,v , >> Box >> -50 -50 >> 0. 3. 1.3 >> 0. 3. 1.3 >> ,SYM, ,O >> >> I get the error for any mesh tolerance value when the scaling coefficients >> are _<_ 0.7 or _>_ 1.3. However it works fine for _>_0.8 and _<_1.2. I >> assume therefore it is that the elements of the mesh near the center of the >> grid are just too small? >> >> Thanks again for your help, >> >> Holly >> >> Holly Johnson >> Masters Student at ONERA - DAFE >> D?partement d'A?rodynamique Fondamentale et Exp?rimentale >> 8, Rue des Vertugadins >> 92190 - Meudon - France >> > -------------- next part -------------- A non-text attachment was scrubbed... Name: t.tar.gz Type: application/octet-stream Size: 8545 bytes Desc: URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: t.t2.gz Type: application/octet-stream Size: 59381 bytes Desc: URL: From nek5000-users at lists.mcs.anl.gov Wed Jun 26 15:14:54 2013 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Wed, 26 Jun 2013 15:14:54 -0500 (CDT) Subject: [Nek5000-users] Problem with Genmap In-Reply-To: References: <51CAFA4D.2050608@onera.fr> Message-ID: Hi Holly, Attached is a tarfile with a script "mkmesh" and a .usr file that will take a regular square grid and compress it near the center. Compression has two components: 1) a tensor-product compression, similar to what you had 2) a pseudo-orthogonal grid concentration The purpose of the second part is to avoid very high aspect ratio cells, which really impact the conditioning of the linear systems and consequently the iteration counts. On this latter point, let me make a couple of comments/questions. In your original script you had a compression factor of 0.7, extended over 50 elements, which would give a largest to smallest ratio of ~ 1.e-8 and you would end up with an aspect ratio of approximately 1.e-6. My guess is that you have something very near the origin that you are trying to resolve and are not interested in the far field. Because of the difficulties with high-aspect ratio elements (which is common to all discretizations, but see pp. 24-26 of www.mcs.anl.gov/~fischer/pubhtml/jcp97.pdf for a discussion related to the SEM), it might be of interest to consider an O-grid, i.e., a cylinder, in which you can easily focus resolution and maintain near unit aspect-ratio throughout the domain. Attached is an example mesh (in t.t2.gz). I can also provide the scripts used to generate this, if of interest. Paul On Wed, 26 Jun 2013, nek5000-users at lists.mcs.anl.gov wrote: > > Hi Holly, > > I've posted this back to the list since it doesn't involve big > data files and the resolution of the problem might be of interest > to others. > > I think I see what's going on and have a couple ideas to fix it. > > Most likely, the reduction attained with 50 elements and a geomtric > progression of 0.7 is wreaking havoc either in the .rea file or in > the tolerances within genmap. A significant issue here is that > the file format in the .rea file is in limited precision --- I think > we can change that with little difficulty and still be compatible > with the workflow. We'll look into that on our end. > > A reasonable work-around, which is what I typically do, would be > to rescale your element coordinates inside nek, and just use a uniform mesh > as the input. I'll send along some code on how to > do this shortly --- along with another approach that will also > give you focused resolution at the origin without the high aspect > ratio elements that will result from the tensor-product approach > used here. > > Paul > > > > On Wed, 26 Jun 2013, Holly Johnson wrote: > >> Hi Paul, >> >> My mesh is actually quite simple, I've had to reduce it from a much more >> complicated version because Visit couldn't handle the number of elements I >> was using. >> >> This is my .box file : >> >> linear.rea >> 2 >> 1 >> # >> # linear.box >> # >> Box >> -50 -50 >> -3. 0. 0.7 >> -3. 0. 0.7 >> SYM, ,v , >> Box >> -50 -50 >> -3. 0. 0.7 >> 0. 3. 1.3 >> SYM, , ,O >> Box >> -50 -50 >> 0. 3. 1.3 >> -3. 0. 0.7 >> ,SYM,v , >> Box >> -50 -50 >> 0. 3. 1.3 >> 0. 3. 1.3 >> ,SYM, ,O >> >> I get the error for any mesh tolerance value when the scaling coefficients >> are _<_ 0.7 or _>_ 1.3. However it works fine for _>_0.8 and _<_1.2. I >> assume therefore it is that the elements of the mesh near the center of the >> grid are just too small? >> >> Thanks again for your help, >> >> Holly >> >> Holly Johnson >> Masters Student at ONERA - DAFE >> D?partement d'A?rodynamique Fondamentale et Exp?rimentale >> 8, Rue des Vertugadins >> 92190 - Meudon - France >> > -------------- next part -------------- A non-text attachment was scrubbed... Name: t.tar.gz Type: application/octet-stream Size: 8545 bytes Desc: URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: t.t2.gz Type: application/octet-stream Size: 59381 bytes Desc: URL: From nek5000-users at lists.mcs.anl.gov Fri Jun 28 02:58:20 2013 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 28 Jun 2013 09:58:20 +0200 Subject: [Nek5000-users] genmap, ABORT: SELF-CHK Message-ID: Hi Paul and Katie, Thank you for your help. Your suggestion of compressing a regular grid in the .usr file is very interesting and I will certainly look into it during the rest of my study. The scripts to generate an O-grid would also be of great interest. Thanks again, Holly Le 26/06/2013 22:14, Paul Fischer a ?crit : > > > Hi Holly, > > Attached is a tarfile with a script "mkmesh" and a .usr file > that will take a regular square grid and compress it near the > center. Compression has two components: > > 1) a tensor-product compression, similar to what you had > > 2) a pseudo-orthogonal grid concentration > > The purpose of the second part is to avoid very high aspect > ratio cells, which really impact the conditioning of the linear > systems and consequently the iteration counts. > > On this latter point, let me make a couple of comments/questions. > > In your original script you had a compression factor of 0.7, > extended over 50 elements, which would give a largest to smallest > ratio of ~ 1.e-8 and you would end up with an aspect ratio of > approximately 1.e-6. > > My guess is that you have something very near the origin that you > are trying to resolve and are not interested in the far field. > Because of the difficulties with high-aspect ratio elements > (which is common to all discretizations, but see pp. 24-26 > of www.mcs.anl.gov/~fischer/pubhtml/jcp97.pdf for a discussion > related to the SEM), it might be of interest to consider an O-grid, > i.e., a cylinder, in which you can easily focus resolution and > maintain near unit aspect-ratio throughout the domain. Attached > is an example mesh (in t.t2.gz). I can also provide the scripts > used to generate this, if of interest. > > Paul > > > > > On Wed, 26 Jun 2013, nek5000-users at lists.mcs.anl.gov wrote: > >> >> Hi Holly, >> >> I've posted this back to the list since it doesn't involve big >> data files and the resolution of the problem might be of interest >> to others. >> >> I think I see what's going on and have a couple ideas to fix it. >> >> Most likely, the reduction attained with 50 elements and a geomtric >> progression of 0.7 is wreaking havoc either in the .rea file or in >> the tolerances within genmap. A significant issue here is that >> the file format in the .rea file is in limited precision --- I think >> we can change that with little difficulty and still be compatible >> with the workflow. We'll look into that on our end. >> >> A reasonable work-around, which is what I typically do, would be >> to rescale your element coordinates inside nek, and just use a >> uniform mesh as the input. I'll send along some code on how to >> do this shortly --- along with another approach that will also >> give you focused resolution at the origin without the high aspect >> ratio elements that will result from the tensor-product approach >> used here. >> >> Paul >> >> >> >> On Wed, 26 Jun 2013, Holly Johnson wrote: >> >>> Hi Paul, >>> >>> My mesh is actually quite simple, I've had to reduce it from a much >>> more complicated version because Visit couldn't handle the number of >>> elements I was using. >>> >>> This is my .box file : >>> >>> linear.rea >>> 2 >>> 1 >>> # >>> # linear.box >>> # >>> Box >>> -50 -50 >>> -3. 0. 0.7 >>> -3. 0. 0.7 >>> SYM, ,v , >>> Box >>> -50 -50 >>> -3. 0. 0.7 >>> 0. 3. 1.3 >>> SYM, , ,O >>> Box >>> -50 -50 >>> 0. 3. 1.3 >>> -3. 0. 0.7 >>> ,SYM,v , >>> Box >>> -50 -50 >>> 0. 3. 1.3 >>> 0. 3. 1.3 >>> ,SYM, ,O >>> >>> I get the error for any mesh tolerance value when the scaling >>> coefficients are _<_ 0.7 or _>_ 1.3. However it works fine for >>> _>_0.8 and _<_1.2. I assume therefore it is that the elements of the >>> mesh near the center of the grid are just too small? >>> >>> Thanks again for your help, >>> >>> Holly >>> >>> Holly Johnson >>> Masters Student at ONERA - DAFE >>> D?partement d'A?rodynamique Fondamentale et Exp?rimentale >>> 8, Rue des Vertugadins >>> 92190 - Meudon - France >>> >> -- Holly Johnson Masters Student at ONERA - DAFE D?partement d'A?rodynamique Fondamentale et Exp?rimentale 8, Rue des Vertugadins 92190 - Meudon - France From nek5000-users at lists.mcs.anl.gov Fri Jun 28 05:21:31 2013 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 28 Jun 2013 12:21:31 +0200 Subject: [Nek5000-users] Import VTK in Prenek from Gmsh Message-ID: Dear Aleks, Ok thank you. Regards, JP -------------- next part -------------- An HTML attachment was scrubbed... URL: From nek5000-users at lists.mcs.anl.gov Fri Jun 28 18:15:32 2013 From: nek5000-users at lists.mcs.anl.gov (nek5000-users at lists.mcs.anl.gov) Date: Fri, 28 Jun 2013 18:15:32 -0500 (CDT) Subject: [Nek5000-users] Import VTK in Prenek from Gmsh In-Reply-To: Message-ID: Hi JP, Please update tools/prenek and check whether the VTK reader works for you now. Best. Aleks ----- Original Message ----- From: nek5000-users at lists.mcs.anl.gov To: "nek5000-users" Sent: Friday, June 28, 2013 5:21:31 AM Subject: Re: [Nek5000-users] Import VTK in Prenek from Gmsh Dear Aleks, Ok thank you. Regards, JP _______________________________________________ Nek5000-users mailing list Nek5000-users at lists.mcs.anl.gov https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users