On Tue, Oct 23, 2012 at 12:50:57PM -0300, Gustavo Seabra wrote:
>
> On 23/10/2012, at 12:37, Reinis wrote:
>
> > On Tue, Oct 23, 2012 at 09:29:28AM -0400, David A Case wrote:
> >> On Tue, Oct 23, 2012, Reinis Danne wrote:
> >>>
> >>> Surprisingly it didn't even build with OpenMP and the issue was raised
> >>> on ML at least once. This fixes the build, but still it is of limited
> >>> utility since it hardcodes the number of threads and sets it to 1 thread
> >>> by default.
> >>
> >> I'm a little lost here. As far as I can see, "make openmp" does not attempt
> >> to do anything with sqm. Can you say what configure and make options you
> >> used, and what the error was?
> >
> > I added $omp_flag to C, C++ and Fortran flags, so everything
> > that had OpenMP directives would be built with it.
> >
> > The first issue was this:
> > qm2_read_nm_and_alloc.F90:816.3:
> >
> > qmmm_omp%diag_threads = qmmm_omp_max_threads
> > 1
> > Error: Unclassifiable statement at (1)
> > qm2_read_nm_and_alloc.F90:817.3:
> >
> > qmmm_omp%pdiag_threads = qmmm_omp_max_threads
> > 1
> > Error: Unclassifiable statement at (1)
> >
> > It didn't know about qmmm_omp structure, which is introduced to it by:
> > use qmmm_module, only : qmmm_omp
> >
> > Then it didn't find the symbol in qmmm_module:
> > qm2_read_nm_and_alloc.F90:27.26:
> >
> > use qmmm_module, only : qmmm_omp
> >
> > Error: Symbol 'qmmm_omp' referenced at (1) not found in module 'qmmm_module'
> > qm2_read_nm_and_alloc.F90:816.3:
> >
> > qmmm_omp%diag_threads = qmmm_omp_max_threads
> > 1
> > Error: Unclassifiable statement at (1)
> > qm2_read_nm_and_alloc.F90:817.3:
> >
> > qmmm_omp%pdiag_threads = qmmm_omp_max_threads
> > 1
> > Error: Unclassifiable statement at (1)
> >
> > Marking it public solves the issue:
> > public :: qmmm_omp
> >
> > The second issue that OMP directive was too long on one line and
> > had to be split in two lines.
> >
> > Regardless if sqm is supposed to be built with OpenMP enabled
> > the code what is there is wrong.
> >
> >>
> >> Amber-developers: is this perhaps unused (or obsolete or unfinished) code?
> >
> > Developers can clarify, but from the code it looked like mostly
> > is used with MPI, but there was also some OMP directives inside
> > MPI ifdefs, so I'm not completely sure if it is expected to be
> > used with MPI alone or it is just dead code there. I still
> > haven't looked at building MPI version of AmberTools.
>
> The OpenMP support in sqm was not thoroughly tested and, as
> far as I understand, its development has been "dormant" for a
> while. Thus, it was disabled in the config, to avoid
> confusion.
>
> I suppose the addition of the $omp_flag made the compiler try
> to use some OpenMP commands available there, but probably not
> all the OpenMP code was compiled, since it is isolated by
> IFDEFs on the code. Have you used -DOPENMP in the
> pre-processing step? That would cause the compilation of the
> whole OpenMP part. (I haven't had any problem with it.)
$omp_flag expands to -fopenmp -DOPENMP and I tried to add it
also to FPPFLAGS and there was no difference, still fails. I'm
also using ifdefs in my patch to isolate OPENMP parts, so it
does receive that directive.
>
> About the "long OpenMP directive", could you indicate which
> line is it?
It is line 1121. I sent full patches with comments and
everything, but why they were not let to the list is beyond me.
>
> Finally, I think Ross would give more details here, but I'd
> guess that enabling OpenMP as a patch right now is not
> advisable, since the results have not been well tested.
Thanks, I would certainly want to hear if it is not a good idea
to enable OpenMP in sqm even if it is using just one OMP thread
which is usless anyway.
Reinis
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Tue Oct 23 2012 - 09:30:02 PDT
