This might be a silly question and/or i am missing a faq but plz help
me. I have a subroutine declared as:
     5         subroutine
lm_a(oidxdn,opnu,opold,oqnu,oqold,                   &
      6
clabl_1,lmx,w_oidn,w_opp,w_oqnu,w_oqold,                        &
      7
d_ialpha,d_ifmt3d,d_itrans,d_jbasdn,d_ldn,d_lmaxw,              &
      8
d_ltmax,d_mdn,d_mmixat,d_mmixpq,d_nbas,d_nclass,d_ndimin,       &
      9
d_ngen,d_nit,d_nitat,d_niter,d_nkdmx,d_nkxyz,d_nl,d_nopts,      &
     10
d_norder,d_npts,d_nrxc,d_nrxyz,d_nsp,                           &
     11
d_as,d_beta,d_dele,d_deltr,d_efermi,d_kap2,d_kfit,              &
     12
d_emax,d_emaxc,d_emin,d_eminc,d_eps,d_facvol,d_gamma,d_ommax1,  &
     13
d_ommax2,d_range,d_rmaxes,d_rmaxs,d_rmaxs2,d_rmines,d_rms2,     &
     14
d_rmsdel,d_tolef,d_toleto,d_tolews,d_vmtz,d_wc,d_width,sw13,    &
     15         asnit)

    In the main program, I have defined an interface
 interface
     43       subroutine
lm_a(oidxdn,opnu,opold,oqnu,oqold,                     &
     44         clabl_1,lmx,&!
w_oidn,w_opp,w_oqnu,w_oqold,                      &
     45
d_ialpha,d_ifmt3d,d_itrans,d_jbasdn,d_ldn,d_lmaxw,              &
     46
d_ltmax,d_mdn,d_mmixat,d_mmixpq,d_nbas,d_nclass,d_ndimin,       &
     47
d_ngen,d_nit,d_nitat,d_niter,d_nkdmx,d_nkxyz,d_nl,d_nopts,      &
     48
d_norder,d_npts,d_nrxc,d_nrxyz,d_nsp,                           &
     49
d_as,d_beta,d_dele,d_deltr,d_efermi,d_kap2,d_kfit,              &
     50
d_emax,d_emaxc,d_emin,d_eminc,d_eps,d_facvol,d_gamma,d_ommax1,  &
     51
d_ommax2,d_range,d_rmaxes,d_rmaxs,d_rmaxs2,d_rmines,d_rms2,     &
     52
d_rmsdel,d_tolef,d_toleto,d_tolews,d_vmtz,d_wc,d_width,switch,
&                asnit)
     53
     54
integer::d_ialpha,d_ifmt3d,d_itrans,d_jbasdn,d_ldn,d_lmaxw,     &
     55
d_ltmax(3),d_mdn,d_mmixat,d_mmixpq,d_nbas,d_nclass,d_ndimin,    &
     56
d_ngen,d_nit,d_nitat,d_niter,d_nkdmx,d_nkxyz(3),d_nl,d_nopts,   &
     57
d_norder,d_npts,d_nrxc,d_nrxyz(3),d_nsp,oidxdn,opnu,opold,oqnu, &
     58
oqold,lmx(200),lmxrho(200),asnit!,oidxdn,opnu,opold,oqnu,oqold
     59         double
precision::d_as,d_beta,d_dele,d_deltr,d_efermi,d_kap2,   &
     60
d_emax,d_emaxc,d_emin,d_eminc,d_eps,d_facvol,d_gamma,d_ommax1(3)&
 
61         ,d_ommax2(3),d_range,d_rmaxes,d_rmaxs,d_rmaxs2,d_rmines,d_rms2,
&
     62
d_rmsdel,d_tolef,d_toleto,d_tolews,d_vmtz,d_wc,d_width,d_kfit
     63         logical:: switch(31)
     64         character(4)::clabl_1
     65       end subroutine lm_a
     66    end interface

and then called the subroutine as
    273 !Function for atom A
    274     call
lm_a(oidxdn,opnu,opold,oqnu,oqold,clabl_1,lmx,                 &
    275
d_ialpha,d_ifmt3d,d_itrans,d_jbasdn,d_ldn,                      &
    276
d_lmaxw,d_ltmax,d_mdn,d_mmixat,d_mmixpq,d_nbas,d_nclass,        &
    277
d_ndimin,d_ngen,d_nit,d_nitat,d_niter,d_nkdmx,d_nkxyz,d_nl,     &
    278
d_nopts,d_norder,d_npts,d_nrxc,d_nrxyz,d_nsp,d_as,d_beta,d_dele,&
    279
d_deltr,d_efermi,d_kap2,d_kfit,d_emax,d_emaxc,d_emin,d_eminc,   &
    280
d_eps,d_facvol,d_gamma,d_ommax1,d_ommax2,d_range,d_rmaxes,      &
    281
d_rmaxs,d_rmaxs2,d_rmines,d_rms2,d_rmsdel,d_tolef,d_toleto,     &
    282         d_tolews,d_vmtz,d_wc,d_width,switch,nit)

but as soon as it getes asnit, it gives segmentation fault, as evident
in the part of the subroutine:
! --- Set up the file logical units ---
    168         write(*,*) "is it here"
    169         write(*,*) asnit
    170     if ((asnit==1).or.(asnit==2))then

 is it here
forrtl: severe (174): SIGSEGV, segmentation fault occurred

i.e. not even writing asnit value.
plz help

rudra wrote:
> This might be a silly question and/or i am missing a faq but plz help
> me. I have a subroutine declared as:
>      5         subroutine
> lm_a(oidxdn,opnu,opold,oqnu,oqold,                   &
>       6
....

> d_rmsdel,d_tolef,d_toleto,d_tolews,d_vmtz,d_wc,d_width,sw13,    &
>      15         asnit)

HEAVENS!!!!

How about grouping a bunch of these arguments into one (or several) UDTs 
or refactor the subroutine (several times maybe?) or some such????

>     In the main program, I have defined an interface
>  interface
>      43       subroutine
> lm_a(oidxdn,opnu,opold,oqnu,oqold,                     &
>      44         clabl_1,lmx,&!
....

> d_rmsdel,d_tolef,d_toleto,d_tolews,d_vmtz,d_wc,d_width,switch,
> &                asnit)
>      53
>      54
> integer::d_ialpha,d_ifmt3d,d_itrans,d_jbasdn,d_ldn,d_lmaxw,     &
>      55
....
> oqold,lmx(200),lmxrho(200),asnit!,oidxdn,opnu,opold,oqnu,oqold
>      59         double
> precision::d_as,d_beta,d_dele,d_deltr,d_efermi,d_kap2,   &
>      60
> d_emax,d_emaxc,d_emin,d_eminc,d_eps,d_facvol,d_gamma,d_ommax1(3)&
....
>      63         logical:: switch(31)
>      64         character(4)::clabl_1
>      65       end subroutine lm_a
>      66    end interface
> 
> and then called the subroutine as
>     273 !Function for atom A
>     274     call
> lm_a(oidxdn,opnu,opold,oqnu,oqold,clabl_1,lmx,                 &
....

Undoubtedly there's a mismatch in one or more of the arguments in the 
subroutine as opposed to the call.

Since you didn't show the actual subroutine declarations, which one is 
impossible to tell (and would be difficult owing to the number if given, 
but at least doable).

As for the interface, put it (the subroutine) in a module and get the 
benefits automagically via USE.

--

I have given the actual subroutine declaration
its not possible to include the lm_a in a module

On 2010-05-25 14:28:52 -0300, rudra <bnrj.rudra@gmail.com> said:

> This might be a silly question and/or i am missing a faq but plz help
> me. I have a subroutine declared as:
>      5         subroutine
> lm_a(oidxdn,opnu,opold,oqnu,oqold,                   &
>       6
> clabl_1,lmx,w_oidn,w_opp,w_oqnu,w_oqold,                        &
>       7
> d_ialpha,d_ifmt3d,d_itrans,d_jbasdn,d_ldn,d_lmaxw,              &
>       8
> d_ltmax,d_mdn,d_mmixat,d_mmixpq,d_nbas,d_nclass,d_ndimin,       &
>       9
> d_ngen,d_nit,d_nitat,d_niter,d_nkdmx,d_nkxyz,d_nl,d_nopts,      &
>      10
> d_norder,d_npts,d_nrxc,d_nrxyz,d_nsp,                           &
>      11
> d_as,d_beta,d_dele,d_deltr,d_efermi,d_kap2,d_kfit,              &
>      12
> d_emax,d_emaxc,d_emin,d_eminc,d_eps,d_facvol,d_gamma,d_ommax1,  &
>      13
> d_ommax2,d_range,d_rmaxes,d_rmaxs,d_rmaxs2,d_rmines,d_rms2,     &
>      14
> d_rmsdel,d_tolef,d_toleto,d_tolews,d_vmtz,d_wc,d_width,sw13,    &
>      15         asnit)
> 
>     In the main program, I have defined an interface
>  interface
>      43       subroutine
> lm_a(oidxdn,opnu,opold,oqnu,oqold,                     &
>      44         clabl_1,lmx,&!
> w_oidn,w_opp,w_oqnu,w_oqold,                      &
>      45
> d_ialpha,d_ifmt3d,d_itrans,d_jbasdn,d_ldn,d_lmaxw,              &
>      46
> d_ltmax,d_mdn,d_mmixat,d_mmixpq,d_nbas,d_nclass,d_ndimin,       &
>      47
> d_ngen,d_nit,d_nitat,d_niter,d_nkdmx,d_nkxyz,d_nl,d_nopts,      &
>      48
> d_norder,d_npts,d_nrxc,d_nrxyz,d_nsp,                           &
>      49
> d_as,d_beta,d_dele,d_deltr,d_efermi,d_kap2,d_kfit,              &
>      50
> d_emax,d_emaxc,d_emin,d_eminc,d_eps,d_facvol,d_gamma,d_ommax1,  &
>      51
> d_ommax2,d_range,d_rmaxes,d_rmaxs,d_rmaxs2,d_rmines,d_rms2,     &
>      52
> d_rmsdel,d_tolef,d_toleto,d_tolews,d_vmtz,d_wc,d_width,switch,
> &                asnit)
>      53
>      54
> integer::d_ialpha,d_ifmt3d,d_itrans,d_jbasdn,d_ldn,d_lmaxw,     &
>      55
> d_ltmax(3),d_mdn,d_mmixat,d_mmixpq,d_nbas,d_nclass,d_ndimin,    &
>      56
> d_ngen,d_nit,d_nitat,d_niter,d_nkdmx,d_nkxyz(3),d_nl,d_nopts,   &
>      57
> d_norder,d_npts,d_nrxc,d_nrxyz(3),d_nsp,oidxdn,opnu,opold,oqnu, &
>      58
> oqold,lmx(200),lmxrho(200),asnit!,oidxdn,opnu,opold,oqnu,oqold
>      59         double
> precision::d_as,d_beta,d_dele,d_deltr,d_efermi,d_kap2,   &
>      60
> d_emax,d_emaxc,d_emin,d_eminc,d_eps,d_facvol,d_gamma,d_ommax1(3)&
> 
> 61         ,d_ommax2(3),d_range,d_rmaxes,d_rmaxs,d_rmaxs2,d_rmines,d_rms2,
> &
>      62
> d_rmsdel,d_tolef,d_toleto,d_tolews,d_vmtz,d_wc,d_width,d_kfit
>      63         logical:: switch(31)
>      64         character(4)::clabl_1
>      65       end subroutine lm_a
>      66    end interface
> 
> and then called the subroutine as
>     273 !Function for atom A
>     274     call
> lm_a(oidxdn,opnu,opold,oqnu,oqold,clabl_1,lmx,                 &
>     275
> d_ialpha,d_ifmt3d,d_itrans,d_jbasdn,d_ldn,                      &
>     276
> d_lmaxw,d_ltmax,d_mdn,d_mmixat,d_mmixpq,d_nbas,d_nclass,        &
>     277
> d_ndimin,d_ngen,d_nit,d_nitat,d_niter,d_nkdmx,d_nkxyz,d_nl,     &
>     278
> d_nopts,d_norder,d_npts,d_nrxc,d_nrxyz,d_nsp,d_as,d_beta,d_dele,&
>     279
> d_deltr,d_efermi,d_kap2,d_kfit,d_emax,d_emaxc,d_emin,d_eminc,   &
>     280
> d_eps,d_facvol,d_gamma,d_ommax1,d_ommax2,d_range,d_rmaxes,      &
>     281
> d_rmaxs,d_rmaxs2,d_rmines,d_rms2,d_rmsdel,d_tolef,d_toleto,     &
>     282         d_tolews,d_vmtz,d_wc,d_width,switch,nit)
> 
> but as soon as it getes asnit, it gives segmentation fault, as evident
> in the part of the subroutine:
> ! --- Set up the file logical units ---
>     168         write(*,*) "is it here"
>     169         write(*,*) asnit
>     170     if ((asnit==1).or.(asnit==2))then
> 
>  is it here
> forrtl: severe (174): SIGSEGV, segmentation fault occurred
> 
> i.e. not even writing asnit value.
> plz help

If you have the source for lm_a then put it in a module and let the compiler
create an interface for you. There is no need for you to be writing interfaces.
There is a good chance you will get it wrong given the untidy source you have
shown.

Segment faults usually come from either subscripts out of range or bad calls.
The problem may or may not be immediately evident. You can eliminate cause
number 2 by letting the compiler generte interfaces which will then catch
the bad calls. See above!

You could also try a debugging setup like the Salford/Silverfrost FTN95 which
will catch all the usual causes. Requires all source and giving up on religous
objections to running under Windows long enough to debug your program. FTN95
is free for personal use.

The pieces you show suggest that any advice will be a pure guess as they could
mean anything. A delayed result of the real cause is as good a guess as any.
It also means that what you have shown is of no help in finding the problem!
To be concrete, one does not know which variables are arrya and which are not
as there declaratons anywhere. A compiler generated inteface wold at least get
that right.

rudra wrote:
> I have given the actual subroutine declaration

You didn't give the variable declarations in the subroutine itself, 
however, nor in the calling routine; only in a separate interface body 
(which there should be no reason for making manually in virtually all 
circumstances)

> its not possible to include the lm_a in a module

Why not?

--

On May 25, 11:03=A0pm, dpb <n...@non.net> wrote:

> > its not possible to include the lm_a in a module
>
> Why not?
this is because, this lm_a is from an old code, used as a library

>You didn't give the variable declarations in the subroutine itself,
Actually, I prefer module over interface, and this is the first time I
am using interface in long time. So, what in my mind is if they are
declered correctly.
I have some confusion, may be a RTFM, but plz reply.
1)inside interface, arguments of the subroutine is as declared in the
main code or as declared in the subroutine source itself?

rudra wrote:
> On May 25, 11:03 pm, dpb <n...@non.net> wrote:
> 
>>> its not possible to include the lm_a in a module
>> Why not?
> this is because, this lm_a is from an old code, used as a library

Meaning you don't have source?  If you have source still don't see why 
it can't become a module.  If you don't then you have compiled version 
that is compatible w/ current other compilers?

>> You didn't give the variable declarations in the subroutine itself,

> Actually, I prefer module over interface, and this is the first time I
> am using interface in long time. So, what in my mind is if they are
> declered correctly.

I don't yet see why you have any need for an explicit interface, but...

> I have some confusion, may be a RTFM, but plz reply.
> 1)inside interface, arguments of the subroutine is as declared in the
> main code or as declared in the subroutine source itself?

All have to be consistent; that's the problem w/ manually writing 
interface blocks; it's your task to ensure each of those independent as 
far as the compiler is concerned definitions are identical.

Normally there are two places; the calling routine and the subroutine 
body.  You've now added a third, the interface body.  The compiler sans 
modules sees all of these as independent compilation units and can't do 
anything to help given that you've deliberately chosen to tie its hands 
by not using modules.

--

rudra <bnrj.rudra@gmail.com> wrote:

> This might be a silly question and/or i am missing a faq

Yes, you are missing a faq.

> I have a subroutine declared as:
  [big mess elided]

>     In the main program, I have defined an interface
  [more mess]

> but as soon as it getes asnit, it gives segmentation fault,
....
> plz help

Off-hand, I'd guess that something is wrong with the subroutine call.
:-) I suppose it might be something wrong somewhere else and showing
symptoms here.

As to what it is, who knows? I can't manage to follow all of what you
did show; it is too big a mess. Odds are that even if I went through and
carefully checked item by item, I still would not find it because you
didn't show everything. The FAQ that you missed is to show the relevant
declarations - *ALL* of them. That is a *VERY* frequent issue; in fact,
I'm quite sure it has come up with you before. No, you have not shown
all the relevant declarations.

With a separate interface body like you have, the relevant declarations
would include at least the declaration of every single argument in all 3
places. Yes, I said 3. The dummy arguments in the subroutine and the
interface body, and the actual arguments in the calling procedure. If
any of the arguments don't have declarations in any of those places,
then you have missed another FAQ - to use implicit none to force
declarations of everything.

In the extreme case, we might have to see the entire subroutine and the
entire caling subroutine because even if we see a declaration for each
argument, that doesn't necessarily mean that there isn't an additional
declaration elsewhere that adds an important attribute. That's probably
going farther than most likely needed, but you are way too far on the
other side.

Alas, even of you do include all the declarations, it is going to be too
big a mess to manually check. I don't put that kind of work into my own
codes; don't see why I should for others. As dpb notes, that kind of a
mess of an argument list is an almost sure sign of... umm... how to put
it at least a little gently... a need for improvement in code design and
organization. That you are having trouble with it is no surprise; pretty
much any human would have trouble with such a mess. We aren't equipped
to grasp that many things all at once. To have a chance of being done
right, non-trivial codes need to be written so that humans can
understand them. It isn't enough for the compiler to do so.

If you really can't reorganize the code better, the next best thing is
to at least put the procedure in a module. That way, you only have 2
places to study instead of 3 (as you no longer have an interface body).
And the compiler will catch a lot of cases of mismatch netween those
two.

Computers do that kind of thing a lot beter than humans. By putting it
in a module, you give more of teh work to the computer, putting less
burden on us poor humans.

You said in response to dpb that it is "not possible" to include the
subroutine in a module. There are very few reasons why that can be "not
possible". Most of them are pretty esoteric and I seriously doubt you
could even name them. (I'd have trouble myself; I could not do it off
the top of my head.) If the code actually has one of those esoteric
things that I can't even recall, maybe that's its problem. But since you
give no hint as to why it is "not possible", that doesn't help much.

All I can say otherwise is to go through each and every argument. Donly
skip one, no matter how trivial it might seem. Check its declaration in
each of the 3 places. Don't guess what you recall it as being or ought
to be. Actually find and look at the declaration. If you can't find one,
see above about implicit none. If it is too much trouble for you to use
implicit none, then it is certainly *WAY* too much trouble for me to
deal with the consequences for you. Yes, checking all of them is going
to take a lot of time, I know.

If "not possible" really means that you don't want to bother, then I
guess my reply has to be that it is not possible for me to debug the
problem based on what you presented. In my case, the "not possible" is a
bit more literal in that the needed information most likely is not
there, and if it is there, the mess is beyond my ability to grasp. I
suppose I could have done the most trivial test and counted the
arguments, but even that seems like too much pain. Taking my shoes off
would not be enough. I'd probably have to take my wife's shoes off as
well.... hmmm. :-)

-- 
Richard Maine                    | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle           |  -- Mark Twain

rudra wrote:

>> > its not possible to include the lm_a in a module
>>
>> Why not?
> this is because, this lm_a is from an old code, used as a library
> 

You seem to imply that in order to write a module you need the source code
for the routines. Not so. A module may contain just interface definitions
with not a single executable statement in it. 

For example:

  MODULE BESSEL_I
    INTERFACE
      FUNCTION J0(X)
        REAL :: X, J0
      END FUNCTION J0
    END INTERFACE
  END MODULE BESSEL_I

> Actually, I prefer module over interface, and this is the first time I
> am using interface in long time. So, what in my mind is if they are
> declered correctly.
> I have some confusion, may be a RTFM, but plz reply.
> 1)inside interface, arguments of the subroutine is as declared in the
> main code or as declared in the subroutine source itself?

The latter, if by "as declared in the main code" you really mean "as invoked
in the caller". A subroutine CALL statement is not a declaration.

-- mecej4

dpb <none@non.net> wrote:

> rudra wrote:
> > On May 25, 11:03 pm, dpb <n...@non.net> wrote:
> > 
> >>> its not possible to include the lm_a in a module
> >> Why not?
> > this is because, this lm_a is from an old code, used as a library
> 
> Meaning you don't have source?  If you have source still don't see why
> it can't become a module.  If you don't then you have compiled version
> that is compatible w/ current other compilers?

Wow. I figured the problem was likely to be in something that wasn't
shown, but I didn't even think about that possibility. Seems like a very
real one, though. Don't skip over that last sentence quoted above too
quickly. That could be a real problem (and the symptoms aren't far off
from what one might expect). I'd suggest recompiling the library with
the *SAME* compiler as you are using for the rest of the code. Note that
"same" is much better than "alleged to be compatible". "Same" also means
the same version as opposed to some previous version from the same
vendor. Oh, and with the same swich settings (I'm thinking of things
like 32-bit vs 64-bit switches, but there are some others as well).

-- 
Richard Maine                    | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle           |  -- Mark Twain

mecej4 <mecej4.nyetspam@operamail.com> wrote:

> A module may contain just interface definitions
> with not a single executable statement in it. 

Yes, but that doesn't help much in the current case. That just moves the
interface body from the main program to the module, but it would still
have all the same problems. It doesn't benefit from the way in which
module procedures get their interfaces generated automatically in such a
way that you know they are correct without having to laboriously check
them item by item.

There are benefits in that, having checked them once, you can then use
the module in multiple places instead of having to redo it for each new
place. But that's not much help in the current case, which only involves
a single place.

-- 
Richard Maine                    | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle           |  -- Mark Twain

rudra wrote:

> This might be a silly question and/or i am missing a faq but plz help
> me. I have a subroutine declared as:

< subroutine declared with 67 arguments > 

>     In the main program, I have defined an interface
< interface declared with 67 arguments >
> 
> and then called the subroutine as

< subroutine call with 63 arguments >

> 
> but as soon as it getes asnit, it gives segmentation fault, as evident
> forrtl: severe (174): SIGSEGV, segmentation fault occurred

as one would expect, given that 63 /= 67.

> plz help

1. Match the number of arguments.
2. Match the types,sizes and shapes of arguments
3. Make sure that any arguments that need to be set have been set.

You have not quite finished step-1.

-- mecej4

mecej4 wrote:

> rudra wrote:
> 
>> This might be a silly question and/or i am missing a faq but plz help
>> me. I have a subroutine declared as:
> 
> < subroutine declared with 67 arguments >
Correction: 68
>>     In the main program, I have defined an interface
> < interface declared with 67 arguments >
Correction: 68
>> 
>> and then called the subroutine as
> 
> < subroutine call with 63 arguments >
Correction: 64
>> 
>> but as soon as it getes asnit, it gives segmentation fault, as evident
>> forrtl: severe (174): SIGSEGV, segmentation fault occurred
> 
> as one would expect, given that 63 /= 67.
> 
>> plz help
> 
> 1. Match the number of arguments.
> 2. Match the types,sizes and shapes of arguments
> 3. Make sure that any arguments that need to be set have been set.
> 
> You have not quite finished step-1.
> 
I overlooked the fact that the number of commas = number of arguments - 1.

-- mecej4

On May 25, 2:35=A0pm, rudra <bnrj.ru...@gmail.com> wrote:
> On May 25, 11:03=A0pm, dpb <n...@non.net> wrote:
>
> > > its not possible to include the lm_a in a module
>
> > Why not?
>
> this is because, this lm_a is from an old code, used as a library

That itself is a different problem. If you have changed compilers or
even compiler versions an older library may well NOT work when lined
to code produced by a later compiler.

For example libraries compiled for Compaq Visual Fortran probably will
not mix with Intel Fortran. Libraries compiled with G77 probably will
not mix with G95 or Gf0rtran. Libraries compiled with G95 may not mix
with Gfortran, and vice versa. Mixing 32 bit code and 64 bit code
should not work.

It's even worse in C or C++. Try mixing libraries compiled with
Borland C++ with MS Visual C++!

Next, mixing compiler versions may not work, for example gcc 4.5 and
gcc 4.0.

Finally, compile options (switch settings) may vary. Steve Lionel
recently answered a qustion in this newsgroup along these lines.
Multiple libraries specified comflicted with each other as well as
differing between debug and release versions.

For the gcc family, you can worry about differences in name
decoration, calling conventions and processor options, etc.

-- e

On May 25, 2:35=A0pm, rudra <bnrj.ru...@gmail.com> wrote:
> On May 25, 11:03=A0pm, dpb <n...@non.net> wrote:
>
> > > its not possible to include the lm_a in a module
>
> > Why not?
>
> this is because, this lm_a is from an old code, used as a library
>
> >You didn't give the variable declarations in the subroutine itself,
>
> Actually, I prefer module over interface, and this is the first time I
> am using interface in long time. So, what in my mind is if they are
> declered correctly.
> I have some confusion, may be a RTFM, but plz reply.
> 1)inside interface, arguments of the subroutine is as declared in the
> main code or as declared in the subroutine source itself?

No, you can just create a module which contains interface blocks. I
did this when I had a supplied library which called the Windows API,
but no source code. I wanted to call these routines from ELF90. I
wrote a module containing interfaces. I also needed to write a wrapper
routine around these libraries (This was Fortran 90.), fortunately
Borland C++ was compatible.

I may still have this code in my archives....

--- Elliot

On May 25, 1:15=A0pm, mecej4 <mecej4.nyets...@operamail.com> wrote:
> rudra wrote:
> > This might be a silly question and/or i am missing a faq but plz help
> > me. I have a subroutine declared as:
>
> < subroutine declared with 67 arguments >
>
> > =A0 =A0 In the main program, I have defined an interface
>
> < interface declared with 67 arguments >
>
>
>
> > and then called the subroutine as
>
> < subroutine call with 63 arguments >
>
>
>
> > but as soon as it getes asnit, it gives segmentation fault, as evident
> > forrtl: severe (174): SIGSEGV, segmentation fault occurred
>
> as one would expect, given that 63 /=3D 67.
>
> > plz help
>
> 1. Match the number of arguments.
> 2. Match the types,sizes and shapes of arguments
> 3. Make sure that any arguments that need to be set have been set.
>
> You have not quite finished step-1.
>
> -- mecej4

Interesting observation.  I wonder if a module would help.

module foo
  implicit none
  private
  public bar
  contains
  subroutine bar(i,j)
    integer i, j
    print *, i, j
  end subroutine bar
end module foo

program atest
  use foo
  call bar(1)
end program atest

troutmask:sgk[211] gfc -o z t.f90
t.f90:14.13:

  call bar(1)
             1
Error: Missing actual argument for argument 'j' at (1)

:-)

--
steve

steve wrote:

> On May 25, 1:15 pm, mecej4 <mecej4.nyets...@operamail.com> wrote:
>> rudra wrote:
>> > This might be a silly question and/or i am missing a faq but plz help
>> > me. I have a subroutine declared as:
>>
>> < subroutine declared with 67 arguments >
>>
>> > In the main program, I have defined an interface
>>
>> < interface declared with 67 arguments >
>>
>>
>>
>> > and then called the subroutine as
>>
>> < subroutine call with 63 arguments >
>>
>>
>>
>> > but as soon as it getes asnit, it gives segmentation fault, as evident
>> > forrtl: severe (174): SIGSEGV, segmentation fault occurred
>>
>> as one would expect, given that 63 /= 67.
>>
>> > plz help
>>
>> 1. Match the number of arguments.
>> 2. Match the types,sizes and shapes of arguments
>> 3. Make sure that any arguments that need to be set have been set.
>>
>> You have not quite finished step-1.
>>
>> -- mecej4
> 
> Interesting observation.  I wonder if a module would help.

Probably not! The routine he is calling is in an "old library", and there is
at least one character*n argument. With IMPLICIT NONE added, he is going to
see more error messages.

We don't know which compiler he used, but the fact that he was able to
produce an a.out (.EXE) file despite having the wrong number of arguments
suggests that the MS decoration @nn was not used. 

> 
> module foo
>   implicit none
>   private
>   public bar
>   contains
>   subroutine bar(i,j)
>     integer i, j
>     print *, i, j
>   end subroutine bar
> end module foo
> 
> program atest
>   use foo
>   call bar(1)
> end program atest
> 
> troutmask:sgk[211] gfc -o z t.f90
> t.f90:14.13:
> 
>   call bar(1)
>              1
> Error: Missing actual argument for argument 'j' at (1)
> 
> :-)
> 
> --
> steve

-- mecej4

mecej4 <mecej4.nyetspam@operamail.com> wrote:

> rudra wrote:
> 
> > This might be a silly question and/or i am missing a faq but plz help
> > me. I have a subroutine declared as:
> 
> < subroutine declared with 67 arguments > 
> 
> >     In the main program, I have defined an interface
> < interface declared with 67 arguments >
> > 
> > and then called the subroutine as
> 
> < subroutine call with 63 arguments >

Good job (even though you later coment off-by-one) of doing the counting
that I said seemed like too much pain. I guess taking off my wife's
shoes wouldn't have been enough either. :-)

I've seen compilers that wouldn't even take that many arguments. I doubt
Intel has a limit that low, but I'm pretty sure I recall a limit of 63
from some compiler or other once. I think I might even have seen lower
ones, but I'm at least a little confident of the 63. (Maybe an old
Microsoft compiler???)

-- 
Richard Maine                    | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle           |  -- Mark Twain

If you do not mind a long post, plz let me allow to post the code
snippets.
You can, if you plz, check the thread
http://software.intel.com/en-us/forums/showthread.php?t=74110
in intel forum as the full code are attached there.

THE SUBROUTINE:
	module mlm_a
!The basic motivation of lm-lib and lm-lib-end is to develop LMTO
!coherently with ASR, so that it could be run as a single unit rather
!then a multiprocess system
	CONTAINS
	subroutine lm_a(oidxdn,opnu,opold,oqnu,oqold, 			&
     	clabl_1,lmx,&!w_oidn,w_opp,w_oqnu,w_oqold,			&
    	d_ialpha,d_ifmt3d,d_itrans,d_jbasdn,d_ldn,d_lmaxw,		&
        d_ltmax,d_mdn,d_mmixat,d_mmixpq,d_nbas,d_nclass,d_ndimin,	&
        d_ngen,d_nit,d_nitat,d_niter,d_nkdmx,d_nkxyz,d_nl,d_nopts,	&
        d_norder,d_npts,d_nrxc,d_nrxyz,d_nsp,				&
   	d_as,d_beta,d_dele,d_deltr,d_efermi,d_kap2,d_kfit,		&
        d_emax,d_emaxc,d_emin,d_eminc,d_eps,d_facvol,d_gamma,d_ommax1,
&
        d_ommax2,d_range,d_rmaxes,d_rmaxs,d_rmaxs2,d_rmines,d_rms2,	&
        d_rmsdel,d_tolef,d_toleto,d_tolews,d_vmtz,d_wc,d_width,asnit)

!	use lmto_init
    	implicit none
    ! Common blocks:
    ! --- dynamical memory allocation:
    integer wksize,asnit
    parameter(wksize=8000000)
    integer w(wksize)
    integer:: w_oidn,w_opp,w_oqnu,w_oqold
    common/wkarr/w
    ! Controls for IO
    integer ishow,ncnt1,ncnt2,mcount
    parameter (ncnt1=1,ncnt2=2,mcount=20)
    character*4 cquit,err,output
    character*8 prgnam
    ! Parameters for options, structure, basis
    integer nbas,nclass,nl,nlrho,nsp,mmixat
    integer nit,nitat,ndel(3),ltmax(3),ifmt3d
    double precision bound(3,6),origin(3),plat(9,6),alat(2)
    logical switch(31),sw13
    integer:: d_ialpha,d_ifmt3d,d_itrans,d_jbasdn,d_ldn,d_lmaxw,	&
         d_ltmax(3),d_mdn,d_mmixat,d_mmixpq,d_nbas,d_nclass,d_ndimin,
&
         d_ngen,d_nit,d_nitat,d_niter,d_nkdmx,d_nkxyz(3),d_nl,d_nopts,
&
         d_norder,d_npts,d_nrxc,d_nrxyz(3),d_nsp
    double
precision::d_as,d_beta,d_dele,d_deltr,d_efermi,d_kap2,d_kfit,&
 
d_emax,d_emaxc,d_emin,d_eminc,d_eps,d_facvol,d_gamma,d_ommax1(3),	&
 
d_ommax2(3),d_range,d_rmaxes,d_rmaxs,d_rmaxs2,d_rmines,d_rms2,	&
         d_rmsdel,d_tolef,d_toleto,d_tolews,d_vmtz,d_wc,d_width
    ! for iterations
    integer niter,mmixpq
    double precision beta,rmsdel,rms2,toleto,wc
    ! Class parameters
    integer mxclas
    parameter (mxclas=200)
    integer:: lmx(mxclas),lmxrho(mxclas),nrclas(mxclas),
konfig(0:3,mxclas)
    double precision:: dq(mxclas),qc(mxclas),qtot(2*mxclas),  &
               ves(2*mxclas),vrmax(2*mxclas),wsr(mxclas),z(mxclas)
    character*4 clabl(mxclas),clabl_1
    ! Symmetry group
    integer nsymop,ngen
    double precision symopm(9,48),symopv(3,48)
    character*72 symops(48),gens(48)
    ! BZ - integration / empty-sphere finder
    integer nkxyz(3),norder,nopts,npts
    double precision emin,eminc,emax,emaxc,range,tolef,width
    ! Empty-sphere finder
    double precision rmaxes,rmines
    integer nrxyz(3)
    ! Scaling wsr
    double precision asavol,facvol,gamma,ommax1(3),ommax2(3)
    ! Structure constant parameters
    integer ialpha,itrans,lmaxw,ndimin,jbasdn,ldn,mdn,nsmesh
    double precision dele,deltr,kap2,kfit,rmaxs,rmaxs2,eps
    ! Parameters relating to Ewald sums
    integer nkdmx
    double precision as,awald,tolews,vol
    ! for rhofit
    integer rfout
    ! for SYML
    integer mxline
    parameter (mxline=99)
    integer nq(mxline),nline
    double precision q1(3,mxline),q2(3,mxline)
    character*1 lab1(mxline),lab2(mxline)
    ! Local variables, functions and offsets to dynamic arrays
    integer fopn,i,ibas,ic,icalc,iprint,isym(10),j,lunit,len2,mxkp, 	&
            nkd,nkg,nkp,npp,nrxc,obeta,oadot0,oalph0,obas,obk,		&
            odlat,oenu,oevrl,oglat,oibk,oiclas,oidmod,oidxdn,onrcls,	&
            opnu,opp,oqnu,osigma,osigm2,otrtab,owk,owtkp,og
    parameter(npp=6)
    double precision avw,avwsr,dovl1(3),dovl2(3),efermi,qb(9),vmtz
    logical begmom,convrg,lsmall,t,f,lpot,lsymst,lsdm1,nowrit
    character*30 csym(7)
    character*6 name,tit
    parameter(t=.true.,f=.false.)
    ! External calls
    external avwsr,chkcls,chkdis,chksym,chkwsr,defdr,defi,dscal,fexit,
&
             finits,fopn,icopy,iprint,lunit,ioctrl,allocm,wkinit
    integer isum,ldim,nderiv,neighm,nmesh,ntet,			&
            oadot,oadoto,oalpha,oalpho,ocg,ocy,odmad,odmat,	&
            oeband,oemom,oiax,oidn,oidtet,oindcg,oirr,oixirr,	&
            ojcg,onpr,opold,oqold,orwats,os,osdot,osdm1,osdm1s,	&
            otrad,otral
    double precision detot,ebmax,ebmin,etot,etoto,sumdq,zval
    character*4 cnit
    data prgnam/'LM'/
    data ialpha/0/,ifmt3d/1/,itrans/0/,jbasdn/1/,ldn/0/,lmaxw/8/,	&
         ltmax/2,2,2/, mdn/0/, mmixat/2/, 				&
         mmixpq/1/, nbas/1/, nclass/1/, ndimin/350/,ngen/0/,nit/1/,	&
         nitat/30/,niter/30/,nkdmx/250/,nkxyz/4,4,4/,nl/3/,		&
         nopts /8001/, norder/0/,npts/1001/,nrxc/1/,nrxyz/0,0,0/,	&
         nsp/1/
    data as/.2d1/, beta/.5d0/,dele/.05d0/,deltr/.1d0/, efermi/-.25d0/,
&
         kap2/.0d0/,kfit/0.d0/ ,emax/.2d1/ ,emaxc/.2d1/ ,emin/-.2d1/,
&
         eminc/-.2d1/,eps/.0d0/,facvol/.1d1/,gamma/.0d0/, 		&
         ommax1/.16d0,.18d0,.20d0/,ommax2/.40d0,.45d0,.50d0/,		&
         range/.5d1/  ,rmaxes/.40d1/,					&
         rmaxs/.32d1/,rmaxs2/.35d1/,rmines/.9d0/,rms2/99.9999999d0/,	&
         rmsdel/.1d-4/,tolef/.1d-5/,toleto/.1d-4/,tolews/.1d-5/,	&
         vmtz/-.75d0/,wc/-.1d1/,width/.5d-2/
    data clabl/mxclas*'E'/, cquit/'----'/, csym/7*'undef'/,		&
         err/'ERRB'/, gens/'E',47*' '/, output/'LM_B'/
    data convrg/f/, switch/t,t,f,t,f,f,f,f,f,t,  t,t,t,f,t,f,f,t,f,f,
&
                           f,f,f,f,t,t,f,f,f,t,  f/


IS MAKEd AS:
..f.o:
	$(FC) -c $(PREFLAGS) $(FFLAGS) $<
	mv $(*F).o $(*D)
#
..c.o:
	$(CC) $(CCFLAGS) -c $<
	mv $(*F).o $(*D)

..f90.o:
	$(FC) -c  $(PREFLAGS) $(FFLAGS) $<

lm-lib.o:MAIN/lm-lib.f90 $(lmobj)#MAIN/lm-lib-end.f90
	$(FC) -c MAIN/lm-lib.f90

THIS IS DONE IN LMTO-A directory, AND MAKEd WITHOUT ANY COMPLAIN

THEN, I HAVE(IN ANOTHER DIRECTORY NAMED ASR)
    program main
    use kinds, only: RDP,i3 !
    use parameters          !Declaring the parameters
    .....
    use mlm_a
    .....
    .....
!Function for atom A
    call lm_a(oidxdn,opnu,opold,oqnu,oqold,clabl_1,lmx,			&
        d_ialpha,d_ifmt3d,d_itrans,d_jbasdn,d_ldn,       		&
 
d_lmaxw,d_ltmax,d_mdn,d_mmixat,d_mmixpq,d_nbas,d_nclass,        &
 
d_ndimin,d_ngen,d_nit,d_nitat,d_niter,d_nkdmx,d_nkxyz,d_nl,     &
 
d_nopts,d_norder,d_npts,d_nrxc,d_nrxyz,d_nsp,d_as,d_beta,d_dele,&
 
d_deltr,d_efermi,d_kap2,d_kfit,d_emax,d_emaxc,d_emin,d_eminc,   &
 
d_eps,d_facvol,d_gamma,d_ommax1,d_ommax2,d_range,d_rmaxes,      &
 
d_rmaxs,d_rmaxs2,d_rmines,d_rms2,d_rmsdel,d_tolef,d_toleto,     &
        d_tolews,d_vmtz,d_wc,d_width,nit)

WHICH IS MAKEd AS:
$(PROG): $(FOBJ)
	$(PFC) $(FFLAGS) $(FPAR) -o ${PROG}  $(FOBJ) -I${LMPATH}/LMTO-A/
(LMPATH IS DEFINED AS /home/rudra/asr_full)
.......
main.o : main.f90 util.o ldos.o fermi.o band.o dos.o \
	 mmat.o hop.o shared.o param.o kind.o cgreen.o \
	 bit_unm.o nis.o pardos.o file.o prinit.o \
	../LMTO-A/lm-lib.o

NOW, WHILE MAKEing, I AM GETTING ERROR:
$ make
ifort -c  -openmp  main.f90
ifort  -openmp  -o irun  band.o cgreen.o dos.o fermi.o hop.o kind.o
ldos.o main.o mmat.o newfit.o param.o pardos.o shared.o thread.o
util.o bit_unm.o nis.o file.o prinit.o  -I/home/rudra/ASR_FULL/LMTO-
A/
main.o: In function `MAIN__':
main.f90:(.text+0xac5): undefined reference to `mlm_a_mp_lm_a_'
make: *** [irun] Error 1

I know its quite messy to find things out from this. Is there any way
or if someone is interested,  I can send the full package...I am
struggling with this problem for last 6 month(if not more).
Plz help

On 5/25/2010 11:58 PM, rudra wrote:
> If you do not mind a long post, plz let me allow to post the code
> snippets.
> You can, if you plz, check the thread
> http://software.intel.com/en-us/forums/showthread.php?t=74110
> in intel forum as the full code are attached there.
>
> THE SUBROUTINE:

<snip>

> IS MAKEd AS:
> .f.o:
> 	$(FC) -c $(PREFLAGS) $(FFLAGS) $<
> 	mv $(*F).o $(*D)
> #
> .c.o:
> 	$(CC) $(CCFLAGS) -c $<
> 	mv $(*F).o $(*D)
>
> .f90.o:
> 	$(FC) -c  $(PREFLAGS) $(FFLAGS) $<
>
> lm-lib.o:MAIN/lm-lib.f90 $(lmobj)#MAIN/lm-lib-end.f90
> 	$(FC) -c MAIN/lm-lib.f90
>
> THIS IS DONE IN LMTO-A directory, AND MAKEd WITHOUT ANY COMPLAIN
>
> THEN  I HAVE(IN ANOTHER DIRECTORY NAMED ASR)

<snip>

> WHICH IS MAKEd AS:
> $(PROG): $(FOBJ)
> 	$(PFC) $(FFLAGS) $(FPAR) -o ${PROG}  $(FOBJ) -I${LMPATH}/LMTO-A/
> (LMPATH IS DEFINED AS /home/rudra/asr_full)
> ......
> main.o : main.f90 util.o ldos.o fermi.o band.o dos.o \
> 	 mmat.o hop.o shared.o param.o kind.o cgreen.o \
> 	 bit_unm.o nis.o pardos.o file.o prinit.o \
> 	../LMTO-A/lm-lib.o
>
> NOW, WHILE MAKEing, I AM GETTING ERROR:
> $ make
> ifort -c  -openmp  main.f90
> ifort  -openmp  -o irun  band.o cgreen.o dos.o fermi.o hop.o kind.o
> ldos.o main.o mmat.o newfit.o param.o pardos.o shared.o thread.o
> util.o bit_unm.o nis.o file.o prinit.o  -I/home/rudra/ASR_FULL/LMTO-
> A/
> main.o: In function `MAIN__':
> main.f90:(.text+0xac5): undefined reference to `mlm_a_mp_lm_a_'
> make: *** [irun] Error 1
>

At this point, seeing your entire makefile (and its entire output) might 
be more useful than seeing the code.  Are you using the "-openmp" flag 
consistently?  What happens if you try to build without -openmp?

As a wild guess, you might be compiling your main program with -openmp 
and your module without it.

Louis

On May 26, 1:15=A0pm, Louis Krupp <lkrupp_nos...@indra.com.invalid>
wrote:
>
> As a wild guess, you might be compiling your main program with -openmp
> and your module without it.

You are right. The module in question(in LMTO-A) is compiled without
openmp while those in ASR is with openmp. But the subroutine in
question is always called outside the openmp region

rudra wrote:
> On May 26, 1:15 pm, Louis Krupp <lkrupp_nos...@indra.com.invalid>
> wrote:
>> As a wild guess, you might be compiling your main program with -openmp
>> and your module without it.
> 
> You are right. The module in question(in LMTO-A) is compiled without
> openmp while those in ASR is with openmp. But the subroutine in
> question is always called outside the openmp region

I don't know anything about the effects of trying that or not; somebody 
else surely does but it would certainly seem worthwhile in eliminating 
the possible discrepancy simply as an expedient test.

But, I notice the previous link step left an unresolved external so 
there's obviously still some problem(s) that shouldn't be too hard to 
sort out to at least get a clean build.

And, I'll return to the previous mantra of the need for a 
self-consistent build of all the pieces w/ all options being 
consistent--it surely sounds and smells like something of the sort may 
be a problem.

Of course, again, w/ such a terribly complex call structure and poorly 
formatted code to even begin to look at, it's quite high probability 
that even if you now have via the module gotten the number and type of 
arguments to agree you still have one or more errors in more subtle ways 
that are index related or so on.

I, as Richard, seem to recall a great deal of confusion earlier on the 
types of argument arrays and a mishmash of styles...there's another 
point of potential problems...

In general, my advice is to step back and reconsider the structure of 
this mess and do something about that first.  If you've had six months 
of no joy going this route it seems clear it's time to look for a path 
to the freeway instead of trying the off-road track over the mountains 
on foot.

--

On May 26, 6:13=A0pm, dpb <n...@non.net> wrote:
>
> In general, my advice is to step back and reconsider the structure of
> this mess and do something about that first. =A0If you've had six months
> of no joy going this route it seems clear it's time to look for a path
> to the freeway instead of trying the off-road track over the mountains
> on foot.

In this case, please suggest me some way out. I am putting the
subroutine source code here(big, but plz have a look). The problem is
I have to split it in two part and use them as a subroutine. looking
eagerly for your help.

      program lm
      implicit none
! Common blocks:
! --- dynamical memory allocation:
      integer wksize
      parameter(wksize=3D8000000)
      integer w(wksize)
      common/wkarr/w
! Controls for IO
      integer ishow,ncnt1,ncnt2,mcount
      parameter (ncnt1=3D1,ncnt2=3D2,mcount=3D20)
      character*4 cquit,err,output
      character*8 prgnam
! Parameters for options, structure, basis
      integer nbas,nclass,nl,nlrho,nsp,mmixat
      integer nit,nitat,ndel(3),ltmax(3),ifmt3d
      double precision bound(3,6),origin(3),plat(9,6),alat(2)
      logical switch(31)

! for iterations
      integer niter,mmixpq
      double precision beta,rmsdel,rms2,toleto,wc
! Class parameters
      integer mxclas
      parameter (mxclas=3D200)
      integer lmx(mxclas),lmxrho(mxclas),nrclas(mxclas),
     .        konfig(0:3,mxclas)
      double precision dq(mxclas),qc(mxclas),qtot(2*mxclas),
     .
ves(2*mxclas),vrmax(2*mxclas),wsr(mxclas),z(mxclas)
      character*4 clabl(mxclas)
! Symmetry group
      integer nsymop,ngen
      double precision symopm(9,48),symopv(3,48)
      character*72 symops(48),gens(48)
! BZ - integration / empty-sphere finder
      integer nkxyz(3),norder,nopts,npts
      double precision emin,eminc,emax,emaxc,range,tolef,width
! Empty-sphere finder
      double precision rmaxes,rmines
      integer nrxyz(3)
! Scaling wsr
      double precision asavol,facvol,gamma,ommax1(3),ommax2(3)
! Structure constant parameters
      integer ialpha,itrans,lmaxw,ndimin,jbasdn,ldn,mdn,nsmesh
      double precision dele,deltr,kap2,kfit,rmaxs,rmaxs2,eps
! Parameters relating to Ewald sums
      integer nkdmx
      double precision as,awald,tolews,vol
! for rhofit
      integer rfout
! for SYML
      integer mxline
      parameter (mxline=3D99)
      integer nq(mxline),nline
      double precision q1(3,mxline),q2(3,mxline)
      character*1 lab1(mxline),lab2(mxline)
! Local variables, functions and offsets to dynamic arrays
      integer fopn,i,ibas,ic,icalc,iprint,isym(10),j,lunit,len2,mxkp,
     .
nkd,nkg,nkp,npp,nrxc,obeta,oadot0,oalph0,obas,obk,
     .        odlat,oenu,oevrl,oglat,oibk,oiclas,oidmod,oidxdn,onrcls,
     .        opnu,opp,oqnu,osigma,osigm2,otrtab,owk,owtkp,og
      parameter(npp=3D6)
      double precision avw,avwsr,dovl1(3),dovl2(3),efermi,
     .       qb(9),vmtz
      logical begmom,convrg,lsmall,t,f,lpot,lsymst,lsdm1,nowrit
      character*30 csym(7)
      character*72 name,tit
      parameter(t=3D.true.,f=3D.false.)
! External calls
      external
avwsr,chkcls,chkdis,chksym,chkwsr,defdr,defi,dscal,fexit,
     .         finits,fopn,icopy,iprint,lunit,ioctrl,allocm,wkinit
      integer isum,ldim,nderiv,neighm,nmesh,ntet,
     .        oadot,oadoto,oalpha,oalpho,ocg,ocy,odmad,odmat,
     .        oeband,oemom,oiax,oidn,oidtet,oindcg,oirr,oixirr,
     .        ojcg,onpr,opold,oqold,orwats,os,osdot,osdm1,osdm1s,
     .        otrad,otral
      double precision detot,ebmax,ebmin,etot,etoto,sumdq,zval
      character*4 cnit
      data prgnam/'LM'/
      data ialpha/0/,ifmt3d/1/,itrans/0/,jbasdn/1/,ldn/0/,lmaxw/8/,
     .     ltmax/2,2,2/, mdn/0/, mmixat/2/,
     .     mmixpq/1/, nbas/1/, nclass/1/, ndimin/350/,ngen/0/,nit/1/,
     .     nitat/30/,niter/30/,nkdmx/250/,nkxyz/4,4,4/,nl/3/,
     .     nopts /801/, norder/0/,npts/1001/,nrxc/1/,nrxyz/0,0,0/,nsp/
1/
      data as/.2d1/, beta/.5d0/,dele/.05d0/,deltr/.1d0/, efermi/-.
25d0/,
     .     kap2/.0d0/,kfit/0.d0/ ,emax/.2d1/ ,emaxc/.2d1/ ,emin/-.
2d1/,
     .     eminc/-.2d1/,eps/.0d0/,facvol/.1d1/,gamma/.0d0/,
     .     ommax1/.16d0,.18d0,.20d0/,ommax2/.40d0,.45d0,.50d0/,
     .     range/.5d1/  ,rmaxes/.40d1/,
     .     rmaxs/.32d1/,rmaxs2/.35d1/,rmines/.9d0/,rms2/99.9999999d0/,
     .     rmsdel/.1d-4/,tolef/.1d-5/,toleto/.1d-4/,tolews/.1d-5/,
     .     vmtz/-.75d0/,wc/-.1d1/,width/.5d-2/
      data clabl/mxclas*'E'/, cquit/'----'/, csym/7*'undef'/,
     .     err/'ERR '/, gens/'E',47*' '/, output/'LM_A'/
      data convrg/f/, switch/t,t,f,t,f,f,f,f,f,t,
t,t,t,f,t,f,f,t,f,f,
     .                       f,f,f,f,t,t,f,f,f,t,  f/
! --- time measure
      call cpusrt('TOTL',t)
      call cpusrt('PRWK',t)
! --- Set up dynamic memory allocation and other initialization ---
      call wkinit(wksize)

! --- Set up the file logical units ---
      call finits
! --- read CTRL file
      do ishow =3D ncnt1,ncnt2
        do i =3D 0, mcount
          call ioctrl(i,prgnam,w(oadot0),alat,w(oalph0),as,avw,
     .                w(obas),beta,bound,clabl,cquit,csym,dele,deltr,
     .                efermi,emax,emaxc,emin,eminc,eps,err,facvol,
     .                gamma,gens,ialpha,icalc,w(oiclas),w(oidmod),
     .                w(oidxdn),ifmt3d,ishow,isym,itrans,jbasdn,kap2,
     .                kfit,konfig,lab1,lab2,ldn,lmaxw,lmx,lmxrho,
     .                lsmall,ltmax,mcount,mdn,mmixat,mmixpq,nbas,
     .                nclass,ndel,ndimin,ngen,nitat,niter,nkdmx,nkp,
     .
nkxyz,nl,nline,nlrho,norder,nopts,npts,nq,nrclas,
     .
nrxc,nrxyz,nsp,nsymop,ommax1,ommax2,origin,output,
     .
plat,w(opnu),w(opp),q1,q2,w(oqnu),range,rfout,rmaxes,
     .                rmaxs,rmaxs2,rmines,rmsdel,w(osigma),w(osigm2),
     .
switch,tit,tolef,toleto,tolews,ves,vmtz,vrmax,wc,
     .                width,wsr,z)
          if (i.eq.6.and.ishow.eq.1) then
! --------- Allocate memory for pp's, moments, basis ....
            call allocm(mxclas,nbas,nclass,nl,nlrho,npp,nsp,oadot0,
     .                  oalph0,obas,oenu,oevrl,oiclas,oidmod,oidxdn,
     .                  opnu,opp,oqnu,osigma,osigm2)
          elseif (i.eq.8.and.ishow.eq.1) then
! --------- Check the symmetry and eventually complete the basis
            call
chksym(alat,clabl,csym,gens,isym,switch(30),switch(10),
     .
lsmall,nbas,nclass,ngen,nrclas,nsymop,obas,oiclas,
     .
otrtab,plat,prgnam,symopm,symops,symopv,switch(3))
! --------- Average Wigner Seitz radius ---
            avw =3D avwsr(plat,alat,vol,nbas)
            if (.not.switch(3).and..not.lsmall)
     .       call chkcls(w(obas),clabl,w(oiclas),w(oidmod),w(oidxdn),
     .
w(otrtab),konfig,lmx,nbas,nclass,nl,nrclas,nsp,
     .                   nsymop,w(opnu),w(opp),prgnam,w(oqnu),wsr,z)
          elseif (i.eq.9.and.ishow.eq.1) then
           call sclwsr(alat,asavol,w(obas),clabl,dovl1,dovl2,facvol,
     .                 gamma,w(oiclas),switch(25),nbas,nclass,nrclas,
     .                 ommax1,ommax2,plat,wsr,z)
           call chkwsr(alat,clabl,nclass,nrclas,plat,wsr,z)
           if(dabs(asavol-facvol).gt.1.d-5)
     .        call errmsg
     .     (' Not space filling: increase number of ES or OMMAX $',4)
          endif
        enddo
        if (ishow.eq.0) then
          call fexit(0,' HELP=3DT encountered')
        elseif (ishow.eq.1) then
          call chkdis(alat,w(obas),clabl,w(oiclas),nbas,nclass,plat,z)
          call gtname(len2,nclass,nrclas,z,name)
          tit =3D name(1:len2)//', '//csym(2)
         if (switch(17).or.switch(8).or.prgnam.eq.'LMHART') then
! -------- Get irreducible mesh points
           nmesh=3D(ndel(1)+1)*(ndel(2)+1)*(ndel(3)+1)
           call defi(oirr  ,  nmesh)
           call defi(oixirr,4*nmesh)
           call makirr(bound,w(oirr),w(oixirr),ndel,nsymop,origin,
     .                 plat,symopm,symopv)
           call rlse(oixirr)
         endif
! --- Set up BZ mesh ---
      mxkp =3D nkxyz(1)*nkxyz(2)*nkxyz(3)
      call defi (oibk ,mxkp)
      call defdr(owtkp,mxkp)
      call defdr(obk  ,mxkp*3)
      call
bzmesh(w(obk),w(oibk),nkxyz(1),nkxyz(2),nkxyz(3),nkp,nsymop,
     .            plat,qb,symopm,w(owtkp))
      call rlse(obk)
      call defdr(obk,3*nkp)
      if (switch(11).and.(switch(12).or.prgnam.eq.'LMDOS')) then
! ----- find inequivalent tetrahedra ---
        call defi(oidtet,mxkp*30)
        call tetirr(w(oibk),w(oidtet),nkxyz(1),nkxyz(2),nkxyz(3),
     .              ntet,qb)
        call rlse(oidtet)
        call defi(oidtet,ntet*5)
      endif
       call cpustp('PRWK',f,f)
! --- Generate Madelung matrix ---
      call defdr(odmad,nbas*nbas)
      call defdr(odlat,3*nkdmx)
      call defdr(oglat,3*nkdmx)
      call lattc(alat,as,awald,w(odlat),w(oglat),nkd,nkdmx,nkg,
     .           plat,tolews)
      call madmat(alat,awald,w(obas),w(odlat),w(odmad),w(oglat),nbas,
     .            nkd,nkg,plat)
      call rlse(odlat)
      if (cquit.eq.'MAD ') call fexit(0,' LM: Q=3DMAD encountered')
! -- Loop for self-consistent calculation ---
!r   In the zeroth iteration, ATOMPP generates pp's from moments
!r   provided switch(4) is set. ATOMSC requires the electrostatic
!r   (Madelung)potential, so a call to MADPOT precedes ATOMSC.
!r   Routine GETQ supplies the charge transfers required by MADPOT.
!r   Routine MADPOT checks that the total system charge is neutral
and
!r   resets ves when it is not.
!r   It is possible to do a band calculation without moments as input,
!r   though pp's are not shifted in the first iteration.
!r   After the first atomic calculation, switch(4) is set so that any
!r   subsequent iterations to self-consistency generate pp's from the
!r   moments.
      call cpusrt('ITET',t)
      do nit=3D0,niter
        begmom =3D switch(4).or.(nit.gt.0)
        write(cnit,'(a1,i3)')'I',nit
        call cpusrt(cnit,t)
! ----  This is the beginning of zeroth iteration ---
! ----- Calculate the charges and ves for coming iteration. Necessary
! ----- that this precede ATOMSC since it requires electrostatic
shifts
        call getq(clabl,dq,konfig,lmx,nclass,nl,nrclas,nsp,w(opnu),qc,
     .            w(oqnu),qtot,sumdq,z,zval)
        call madpot(clabl,w(odmad),w(oiclas),nbas,nclass,qtot,ves,wsr)
        call atomsc(begmom,clabl,switch(14),detot,dq,w(oenu),
     .              etot,w(oevrl),kap2,konfig,switch(17).or.switch(8),
     .              switch(29),switch(21),switch(6),switch(18),lmx,
     .              switch(28),switch(1),mmixat,nclass,nitat,nl,
     .              switch(9),nrclas,nrxc,nsp,w(opnu),qc,w(oqnu),qtot,
     .              ves,vmtz,vrmax,wsr,z)
        if (begmom) call enutpp(w(oenu),w(oidmod),nclass,nl,npp,nsp,
     .                          w(opp))
        call atompp(avw,clabl,kap2,switch(6),lmx,switch(1),nclass,
     .              nl,nsp,w(opp),w(osigma),ves,vmtz,wsr,z)

<=3D=3D=3D=3D=3DTHIS MUCH SHOULD BE IN FIRST ROUTINE AND SECOND IN THE
LATER=3D=3D=3D=3D=3D=3D>

        if (nit.ne.0) detot =3D etot - etoto
        etoto =3D etot
        if (begmom.and.iprint().ge.0)
     .    write(lunit(1),301)nit,niter,sumdq,etot,rms2,detot
        if (cquit.eq.'ATOM') call fexit(0,' LM: Q=3DATOM encountered')
        if (switch(6)) call fexit(0,' LM: FREE=3DT encountered')
! ----- Check for convergence ---
        convrg=3D(rms2.lt.rmsdel.and.dabs(detot).lt.toleto)
        if (.not.convrg.and.nit.ne.niter) then
! ------- Make copy of old p's and q's and downfolding indices ---
          call defdr(opold,nl*nsp*nclass)
          call defdr(oqold,nl*nsp*nclass*3)
          call defi (oidn ,nl*nclass)
          call icopy(nl*nclass,w(oidxdn),1,w(oidn),1)
          call dcopy(nl*nsp*nclass  ,w(opnu),1,w(opold),1)
          call dcopy(nl*nsp*nclass*3,w(oqnu),1,w(oqold),1)
          if(switch(8)) call defdr(oemom,-3*nl**4*nsp*nbas)
! ------- Band calculation ---
          call bndasa(alat,avw,w(obas),w(obk),clabl,dele,
     .                ebmax,ebmin,efermi,emaxc,eminc,w(oemom),
     .                w(oevrl),w(oiclas),w(oidtet),w(oidn),kap2,
     .                ldim,lmx,nbas,nclass,neighm,nkp,nkxyz,nl,
     .                norder,npts,nrclas,nsp,nsymop,ntet,oadot,oalpha,
     .                odmat,oeband,oiax,onpr,os,osdot,plat,w(opp),
     .                w(oqnu),range,w(osigma),switch,symopm,symopv,
     .                tolef,vmtz,width,wsr,w(owtkp),zval)
          if (switch(23)) then
            call bzlabs(lab1,lab2,nline,q1,q2)
            call wrlmfs(alat,w(obk),w(oeband),efermi,w(oibk),isym(1),
     .                  ldim,nkxyz(1),nkxyz(2),nkxyz(3),nkp,nsp,plat)
          endif
          if (switch(17))
     .      call dens(alat,avw,bound,clabl,ifmt3d,w(oirr),kap2,
     .
switch(29),switch(21),lmx,switch(24),nbas,nclass,
     .                ndel,neighm,nl,nsp,obas,odmat,oiax,oiclas,oidn,
     .                onpr,opp,origin,os,plat,wsr,z)
          if (switch(8))
     .      call rhofit(alat,avw,w(obas),bound,clabl,deltr,w(oemom),
     .                  w(oiclas),w(oidn),ifmt3d,w(oirr),kfit,lmaxw,
     .                  lmx,lmxrho,nbas,nclass,ndel,nl,nlrho,nrclas,
     .                  nsp,origin,plat,rfout,rmaxs2,w(orwats),
     .                  w(osigm2),wsr,z,zval)
! ------- Transform to the orthogonal representation
          call ortrep(clabl,w(oidn),nclass,nl,nsp,w(opp),w(oqnu))
!-------- Shift enu to center of gravity and calculate new moments
!-------- and backup old qnu's and pnu's
          call enutcg(avw,clabl,w(oevrl),w(oidmod),kap2,lmx,
     .                nclass,nl,nsp,w(opnu),w(opp),w(oqnu),wsr)
! ------- Mixing moments and pnu's
          call mixpq(beta,switch(13),clabl,lmx,mmixpq,nclass,nl,nsp,
     .               w(opnu),w(opold),w(oqnu),w(oqold),rms2,wc)
          call rlse(opold)
          if (cquit.eq.'BAND_A') call fexit(0,' LM: Q=3DBAND
encountered')
        endif
        call cpustp(cnit,f,f)
        if (convrg.or.switch(17).or.switch(8)) goto 1
      enddo
1     call cpustp('ITET',f,f)
! --- End of the self-consistency loop

        if(convrg) call atompp1(avw,clabl,kap2,switch(6),lmx,
     .              switch(1),nclass,
     .              nl,nsp,w(opp),w(osigma),ves,vmtz,wsr,z)

      if (convrg) write(lunit(1),302) rms2,dabs(detot)
      emax=3D(idnint(ebmax*10)+1)*0.1d0
      emin=3D(idnint(ebmin*10)-1)*0.1d0
 301  format(/72('#')//'ITER',i3,' OUT OF',i3,':   MAG MOM=3D',f12.8,
     .             3x,'ETOT=3D',f17.8,/22x,'RMS DQ=3D',f12.8,
     .            2x,'DETOT=3D',f17.8//72('#')/)
 302  format(/' Jolly good show!  You converged to rms DQ=3D',f10.8,
     .       /' Jolly good show!  You converged to  DETOT=3D',f10.8)
        endif
      enddo
      call timres(clabl,nbas,nclass,nit)
      call fexit(0,prgnam)
      end

plz help

On 5/26/2010 2:46 AM, rudra wrote:
> On May 26, 1:15 pm, Louis Krupp<lkrupp_nos...@indra.com.invalid>
> wrote:
>>
>> As a wild guess, you might be compiling your main program with -openmp
>> and your module without it.
>
> You are right. The module in question(in LMTO-A) is compiled without
> openmp while those in ASR is with openmp. But the subroutine in
> question is always called outside the openmp region

I'll repeat my question:  If you compile everything without -openmp, 
what happens?  What happens if you compile everything with -openmp?

If compiling part of it one way and part of it another is a problem, 
then don't do that.  If, for some reason, you have to do it that way, 
then someone who understands openmp might be able to help you.

Louis

"rudra" <bnrj.rudra@gmail.com> wrote in message 
news:0e99e8fe-9010-46df-9754-c54f93033ffe@g39g2000pri.googlegroups.com...
> If you do not mind a long post, plz let me allow to post the code
> snippets.
> You can, if you plz, check the thread
> http://software.intel.com/en-us/forums/showthread.php?t=74110
> in intel forum as the full code are attached there.
>
>

Apart from all the modules that are USEd by main.f90

First I tried to cut down main - cutting out everything except the 
declarations and the calls to lm_a and lm_end.
AND I put lm_a and lm_end into modules "m_lma" and "m_lm_end" respectively 
(which you said you could not do but I don't know why)
I then added USE m_lm_a     and USE m_lm_end to main

I got the following :

This was for the call to lm_a
"ivftest\main.F90(132): error #6784: The number of actual arguments cannot 
be greater than the number of dummy arguments."
whish was pointed out by mecej4

and for the call to lm_end
ivftest\main.F90(161): error #6784: The number of actual arguments cannot be 
greater than the number of dummy arguments.


and several of the form :
ivftest\main.F90(132): error #6633: The type of the actual argument differs 
from the type of the dummy argument.

whether these are real mismatches or
  caused by the displacement of the actual vs dummy arguments or
  were caused by my not having the modules for main
I can't say (I didn't look too closely)

then I got "too many errors compilation aborted"

Les 

There is no improvement/change when I compiled everything without
openmp

rudra wrote:
> On May 26, 6:13 pm, dpb <n...@non.net> wrote:
>> In general, my advice is to step back and reconsider the structure of
>> this mess and do something about that first.  If you've had six months
>> of no joy going this route it seems clear it's time to look for a path
>> to the freeway instead of trying the off-road track over the mountains
>> on foot.
> 
> In this case, please suggest me some way out. ...

My standard rates apply.

I don't see how you can expect somebody to look at this as a service and 
solve your problem in a few minutes if you've been unable to do so in 
six months.

I also don't know where the specific source you're posting came from or 
what you've done with it but I'm pretty sure I'd only consider starting 
from the beginning point prior to any mucking around and with an 
objective from that point rather than trying to patch up this.

--

rudra wrote:

> I know its quite messy to find things out from this. Is there any way

E.J. Dijkstra's Rule-1 for programmers: DON'T MAKE A MESS.

> or if someone is interested,  

There are some people who repeatedly and vociferously ask for help but, when
good advice is given benevolently, either ignore it or dismiss it without
much thought. Of such people it is sometimes said that "they adamantly want
to remain helpless, so there is no point helping them".

And then there are others who, after having repeatedly tried a method to
solve a problem and having failed every time, persist in making more
attempts with the same method with the hope that some day it will bring
them success.

Do you want to be in either of these categories?

Three people have told you that your subroutine calls have the arguments
mismatched in number and type. So far you have ignored these posts.

> I can send the full package...I am 
> struggling with this problem for last 6 month(if not more).

No, keep it, and struggle as long as it pleases you or it is your lot in
life, since that seems to be your chosen path to bliss.

> Plz help

Sorry, no more. It's wasted effort, given the target. There is an old saying
that one should not try to squeeze butter out of a piece of granite.

-- mecej4

rudra wrote:

> There is no improvement/change when I compiled everything without
> openmp

That's to be expected. Given buggy serial code, adding OpenMP on top of it
is like putting a rose garland around the neck of a starved horse and
expecting it to win the race.

-- mecej4

On May 26, 7:28=A0pm, mecej4 <mecej4.nyets...@operamail.com> wrote:
>
> Three people have told you that your subroutine calls have the arguments
> mismatched in number and type. So far you have ignored these posts.
>

Not really!!
I have managed to cleanup the argument list, and that I was about to
post. But then I also found Les's post and make it what he has said.
which now looks like as:
     1     implicit none
      2
      3 !
***********************************************************************!
      4    interface
      5       subroutine
lm_a(oidxdn,opnu,opold,oqnu,oqold,                     &
      6         clabl_1,lmx,&!
w_oidn,w_opp,w_oqnu,w_oqold,                      &
      7
d_ialpha,d_ifmt3d,d_itrans,d_jbasdn,d_ldn,d_lmaxw,              &
      8
d_ltmax,d_mdn,d_mmixat,d_mmixpq,d_nbas,d_nclass,d_ndimin,       &
      9
d_ngen,d_nit,d_nitat,d_niter,d_nkdmx,d_nkxyz,d_nl,d_nopts,      &
     10
d_norder,d_npts,d_nrxc,d_nrxyz,d_nsp,                           &
     11
d_as,d_beta,d_dele,d_deltr,d_efermi,d_kap2,d_kfit,              &
     12
d_emax,d_emaxc,d_emin,d_eminc,d_eps,d_facvol,d_gamma,d_ommax1,  &
     13
d_ommax2,d_range,d_rmaxes,d_rmaxs,d_rmaxs2,d_rmines,d_rms2,     &
     14
d_rmsdel,d_tolef,d_toleto,d_tolews,d_vmtz,d_wc,d_width,switch,  &
     15          asnit)
     16
     17
integer::d_ialpha,d_ifmt3d,d_itrans,d_jbasdn,d_ldn,d_lmaxw,     &
     18
d_ltmax(3),d_mdn,d_mmixat,d_mmixpq,d_nbas,d_nclass,d_ndimin,    &
     19
d_ngen,d_nit,d_nitat,d_niter,d_nkdmx,d_nkxyz(3),d_nl,d_nopts,   &
     20
d_norder,d_npts,d_nrxc,d_nrxyz(3),d_nsp,oidxdn,opnu,opold,oqnu, &
     21
oqold,lmx(200),lmxrho(200),asnit!,oidxdn,opnu,opold,oqnu,oqold
     22         double
precision::d_as,d_beta,d_dele,d_deltr,d_efermi,d_kap2,   &
     23
d_emax,d_emaxc,d_emin,d_eminc,d_eps,d_facvol,d_gamma,d_ommax1(3)&
=20
24         ,d_ommax2(3),d_range,d_rmaxes,d_rmaxs,d_rmaxs2,d_rmines,d_rms2,
&
     25
d_rmsdel,d_tolef,d_toleto,d_tolews,d_vmtz,d_wc,d_width,d_kfit
     26         logical:: switch(31)
     27         character(4)::clabl_1
     28       end subroutine lm_a
     29
     30       subroutine
lm_end(oidxdn,opnu,opold,oqnu,oqold,                   &
     31         clabl_1,lmx,&!
w_oidn,w_opp,w_oqnu,w_oqold,                      &
     32
ialpha,ifmt3d,itrans,jbasdn,ldn,lmaxw,                          &
     33         ltmax, mdn,mmixat,mmixpq, nbas,d_nclass,
ndimin,ngen,nit,       &
     34
nitat,niter,nkdmx,nkxyz,d_nl,nopts,norder,npts,nrxc,nrxyz,d_nsp,&
     35         as, beta,dele,deltr,
efermi,kap2,kfit,emax,emaxc,emin,          &
     36
eminc,eps,facvol,gamma,ommax1,ommax2,range,rmaxes,              &
     37
rmaxs,rmaxs2,rmines,rms2,rmsdel,tolef,toleto,tolews,vmtz,wc,    &
     38         width,switch)
     39
     40
integer::d_ialpha,d_ifmt3d,d_itrans,d_jbasdn,d_ldn,d_lmaxw,     &
     41
ltmax(3),d_mdn,d_mmixat,d_mmixpq,d_nbas,d_nclass,d_ndimin,      &
     42
d_ngen,d_nit,d_nitat,d_niter,nkdmx,nkxyz(3),d_nl,d_nopts,       &
     43
d_norder,d_npts,d_nrxc,nrxyz(3),d_nsp,oidxdn,opnu,opold,oqnu,   &
     44         oqold,lmx(200),lmxrho(200)
     45         character(4)::clabl_1
     46         double
precision::as,beta,dele,deltr,efermi,kap2,               &
     47
emax,emaxc,emin,eminc,eps,facvol,gamma,ommax1(3)                &
=20
48         ,ommax2(3),range,rmaxes,rmaxs,rmaxs2,rmines,rms2,
&
     49         rmsdel,tolef,toleto,tolews,vmtz,wc,width,kfit
     50         logical switch(31)
     51         end subroutine lm_end
     52
     53         subroutine
lm_b(oidxdn_b,opnu_b,opold_b,oqnu_b,oqold_b,         &
     54
clabl_1_b,lmx_b,d_ialpha_b,d_ifmt3d_b,                          &
     55
d_itrans_b,d_jbasdn_b,d_ldn_b,d_lmaxw_b,d_ltmax_b,d_mdn_b,      &
     56
d_mmixat_b,d_mmixpq_b,d_nbas_b,d_nclass_b,d_ndimin_b,d_ngen_b,  &
     57
d_nit_b,d_nitat_b,d_niter_b,d_nkdmx_b,d_nkxyz_b,d_nl_b,         &
     58
d_nopts_b,d_norder_b,d_npts_b,d_nrxc_b,d_nrxyz_b,d_nsp_b,d_as_b,&
     59
d_beta_b,d_dele_b,d_deltr_b,d_efermi_b,d_kap2_b,d_kfit_b,       &
     60
d_emax_b,d_emaxc_b,d_emin_b,d_eminc_b,d_eps_b,d_facvol_b,       &
     61
d_gamma_b,d_ommax1_b,d_ommax2_b,d_range_b,d_rmaxes_b,d_rmaxs_b, &
     62
d_rmaxs2_b,d_rmines_b,d_rms2_b,d_rmsdel_b,d_tolef_b,d_toleto_b, &
     63         d_tolews_b,d_vmtz_b,d_wc_b,d_width_b,switch,asnit)
     64
     65
integer::d_ialpha_b,d_ifmt3d_b,d_itrans_b,d_jbasdn_b,d_ldn_b,   &
     66
d_lmaxw_b,d_ltmax_b(3),d_mdn_b,d_mmixat_b,d_mmixpq_b,d_nbas_b,  &
     67
d_nclass_b,d_ndimin_b,d_ngen_b,d_nit_b,d_nitat_b,d_niter_b,     &
     68
d_nkdmx_b,d_nkxyz_b(3),d_nl_b,d_nopts_b,d_norder_b,d_npts_b,    &
     69
d_nrxc_b,d_nrxyz_b(3),d_nsp_b,oidxdn_b,opnu_b,opold_b,oqnu_b, &
     70         oqold_b,lmx_b(200),asnit
     71
     72         character(4)::clabl_1_b
     73         logical::switch(31)
     74         double
precision::d_as_b,d_beta_b,d_dele_b,d_deltr_b,d_efermi_b,&
     75         d_kap2_b,
d_emax_b,d_emaxc_b,d_emin_b,d_eminc_b,d_eps_b,        &
     76
d_facvol_b,d_gamma_b,d_ommax1_b(3),d_ommax2_b(3),d_range_b,     &
     77
d_rmaxes_b,d_rmaxs_b,d_rmaxs2_b,d_rmines_b,d_rms2_b,d_rmsdel_b, &
     78
d_tolef_b,d_toleto_b,d_tolews_b,d_vmtz_b,d_wc_b,d_width_b,      &
 79         d_kfit_b
     80         end subroutine lm_b
     81
     82         end interface
     83
     84 !       LMTO variables
     85
integer::d_ialpha,d_ifmt3d,d_itrans,d_jbasdn,d_ldn,d_lmaxw,     &
     86
d_ltmax(3),d_mdn,d_mmixat,d_mmixpq,d_nbas,d_nclass,d_ndimin,    &
     87
d_ngen,d_nit,d_nitat,d_niter,d_nkdmx,d_nkxyz(3),d_nl,d_nopts,   &
     88
d_norder,d_npts,d_nrxc,d_nrxyz(3),d_nsp,oidxdn,opnu,opold,oqnu, &
     89         oqold,lmx(200),lmxrho(200),nit
     90         character(4)::clabl_1
     91         logical::switch(31)
     92
     93         double
precision::d_as,d_beta,d_dele,d_deltr,d_efermi,d_kap2,   &
     94
d_emax,d_emaxc,d_emin,d_eminc,d_eps,d_facvol,d_gamma,d_ommax1(3)&
=20
95         ,d_ommax2(3),d_range,d_rmaxes,d_rmaxs,d_rmaxs2,d_rmines,d_rms2,
&
     96
d_rmsdel,d_tolef,d_toleto,d_tolews,d_vmtz,d_wc,d_width,d_kfit
     97
     98
integer::d_ialpha_b,d_ifmt3d_b,d_itrans_b,d_jbasdn_b,d_ldn_b,   &
     99
d_lmaxw_b,d_ltmax_b(3),d_mdn_b,d_mmixat_b,d_mmixpq_b,d_nbas_b,  &
    100
d_nclass_b,d_ndimin_b,d_ngen_b,d_nit_b,d_nitat_b,d_niter_b,     &
    101
d_nkdmx_b,d_nkxyz_b(3),d_nl_b,d_nopts_b,d_norder_b,d_npts_b,    &
    102
d_nrxc_b,d_nrxyz_b(3),d_nsp_b,oidxdn_b,opnu_b,opold_b,oqnu_b,   &
    103         oqold_b,lmx_b(200)
    104
    105         double
precision::d_as_b,d_beta_b,d_dele_b,d_deltr_b,d_efermi_b,&
    106         d_kap2_b,
d_emax_b,d_emaxc_b,d_emin_b,d_eminc_b,d_eps_b,        &
    107
d_facvol_b,d_gamma_b,d_ommax1_b(3),d_ommax2_b(3),d_range_b,     &
    108
d_rmaxes_b,d_rmaxs_b,d_rmaxs2_b,d_rmines_b,d_rms2_b,d_rmsdel_b, &
    109
d_tolef_b,d_toleto_b,d_tolews_b,d_vmtz_b,d_wc_b,d_width_b,      &
    110         d_kfit_b
    111         character(4)::clabl_1_b
    112
    113
    114         call
lm_a(oidxdn,opnu,opold,oqnu,oqold,clabl_1,lmx,             &
    115
d_ialpha,d_ifmt3d,d_itrans,d_jbasdn,d_ldn,                      &
    116
d_lmaxw,d_ltmax,d_mdn,d_mmixat,d_mmixpq,d_nbas,d_nclass,        &
    117
d_ndimin,d_ngen,d_nit,d_nitat,d_niter,d_nkdmx,d_nkxyz,d_nl,     &
    118
d_nopts,d_norder,d_npts,d_nrxc,d_nrxyz,d_nsp,d_as,d_beta,d_dele,&
    119
d_deltr,d_efermi,d_kap2,d_kfit,d_emax,d_emaxc,d_emin,d_eminc,   &
    120
d_eps,d_facvol,d_gamma,d_ommax1,d_ommax2,d_range,d_rmaxes,      &
    121
d_rmaxs,d_rmaxs2,d_rmines,d_rms2,d_rmsdel,d_tolef,d_toleto,     &
    122         d_tolews,d_vmtz,d_wc,d_width,switch,nit)
    123
    124
    125         call
lm_end(oidxdn,opnu,opold,oqnu,oqold,clabl_1,lmx,           &
    126
d_ialpha,d_ifmt3d,d_itrans,d_jbasdn,d_ldn,                      &
    127
d_lmaxw,d_ltmax,d_mdn,d_mmixat,d_mmixpq,d_nbas,d_nclass,        &
    128
d_ndimin,d_ngen,d_nit,d_nitat,d_niter,d_nkdmx,d_nkxyz,d_nl,     &
    129
d_nopts,d_norder,d_npts,d_nrxc,d_nrxyz,d_nsp,d_as,d_beta,d_dele,&
    130
d_deltr,d_efermi,d_kap2,d_kfit,d_emax,d_emaxc,d_emin,d_eminc,   &
    131
d_eps,d_facvol,d_gamma,d_ommax1,d_ommax2,d_range,d_rmaxes,      &
    132
d_rmaxs,d_rmaxs2,d_rmines,d_rms2,d_rmsdel,d_tolef,d_toleto,     &
    133         d_tolews,d_vmtz,d_wc,d_width,switch)
    134
    135         end

$ ifort trylmto.f90 -L/home/Rudra/LMTO-ASR-DISTRO_NEW/LMTO-A -llm_a
$
so, compilation is done! offcourse some runtime error is still there
and thats why i asked for idea...if you read my last but 1 post, what
I really asked is to give some better idea of splitting the code.

rudra wrote:
....

> ... what I really asked is to give some better idea of splitting the
> code.

To amplify my response somewhat from earlier on the subject...

That would require stepping back and looking at the overall objective of 
the project as a start, followed by an evaluation of what the pieces are 
at present and then a plan to get to the object end.

Once one has that overall grasp, then one can begin to look at the 
structure of the existing codes and see what makes sense from their 
present structure (or, sadly, lack thereof is what one finds far too 
often in legacy code).  At that point some decisions can be made as to 
how to proceed; sometimes, even, the logical decision is to throw the 
baby out w/ the bath water and start again if the code base is already 
truly horrible and the objective is valuable (and particularly if it is 
long term rather than simply a one-time hack).

But, assuming the answer is to try to meld some pieces together, it 
surely should be possible after six months to have enough of an idea of 
how the code works and what it does that there is some logic in making 
data structures of related parts that can be placed in call lists as 
composites, other data that may be so widely interspersed as to be 
likely candidates for module-level variables, and such general levels of 
abstraction.

Then, of course, there's the idea of factorization of the code itself 
into compilation units that do a more restricted piece of the puzzle so 
they _don't_ have to know the whole world to operate.

That isn't a five-minute task by any means, granted.  But, you've spent 
six-months and have apparently nothing to show so another month or so 
that might lead to some results afterwards wouldn't seem to bad an 
investment.

Of course, there's also the expedient (assuming this is real work and 
not either coursework or just personal entertainment) of hiring some 
"real" help either to do the project or at consult on it.

(And, no, I personally really, really don't want to be that person; I am 
happily retired (from technical consulting anyway) and am fully 
intending on staying that way (unless, of course, somebody makes an 
offer I just can't refuse... :) ).

Anyway, while in theory it's possible you can get through the jumbled 
tangled mess you have posted and come out the other side, I personally 
think a rehash and reboot would likely lead to the promised land at 
least as quickly and would have a higher value on the other end.

--

dpb <none@non.net> wrote:

> That isn't a five-minute task by any means, granted.  But, you've spent
> six-months and have apparently nothing to show so another month or so
> that might lead to some results afterwards wouldn't seem to bad an 
> investment.

Unless the 6 months has all been spent attempting to do the kinds of
spot fixes that so many of the questions seem to indicate, without much
looking at the bigger picture, in which case another month of the same
is likely to give the same results.

> Of course, there's also the expedient (assuming this is real work and
> not either coursework or just personal entertainment) of hiring some 
> "real" help either to do the project or at consult on it.
> 
> (And, no, I personally really, really don't want to be that person; I am
> happily retired (from technical consulting anyway) and am fully 
> intending on staying that way (unless, of course, somebody makes an 
> offer I just can't refuse... :) ).

Very much the same. And for those who might think such professional
consulting is cheap. Well, I've never actually established rates, as,
like dpb, I'd rather stay retired. But I was making a bit over $500/day
plus benefits at a regular, full-time job when I retired. As a general
rule, consulting usually runs several times the daily rate of a
full-time job, and does tend to be billed in daily increments, even for
part of a day, and comes with no guarantee of results. Something that
just matched the "general rule" would not count as an offer I could not
refuse. No, I'm not holding my breath.

-- 
Richard Maine                    | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle           |  -- Mark Twain

On 5/26/2010 8:16 AM, rudra wrote:
> There is no improvement/change when I compiled everything without
> openmp
>

And exactly what happened?  What error message(s) did you get?

Have you made sure you're recompiling absolutely everything?  That's 
always a potential problem with makefiles:  Unless the makefile itself 
is a dependency, you have to a "make clean" (or the manual equivalent) 
if you change anything in the makefile.

Louis

Richard Maine wrote:
> dpb <none@non.net> wrote:
> 
>> That isn't a five-minute task by any means, granted.  But, you've spent
>> six-months and have apparently nothing to show so another month or so
>> that might lead to some results afterwards wouldn't seem to bad an 
>> investment.
> 
> Unless the 6 months has all been spent attempting to do the kinds of
> spot fixes that so many of the questions seem to indicate, without much
> looking at the bigger picture, in which case another month of the same
> is likely to give the same results.
....

Oh, very much so I meant a month of actual overall design and analysis 
and that sorta' thing; I've not doubt that an infinite supply of months 
won't help at the way they're being expended at the moment, unfortunately.

--

On May 27, 12:26=A0am, Louis Krupp <lkrupp_nos...@indra.com.invalid>
wrote:
>
> Have you made sure you're recompiling absolutely everything? =A0
>
> Louis
Thanks Louis.
But I made everything from scratch again

On 5/26/2010 9:59 PM, rudra wrote:
> On May 27, 12:26 am, Louis Krupp<lkrupp_nos...@indra.com.invalid>
> wrote:
>>
>> Have you made sure you're recompiling absolutely everything?
>>
>> Louis
> Thanks Louis.
> But I made everything from scratch again

And now it compiles and links and runs?  No errors or warnings?

Well done!

Louis

On May 27, 11:21=A0am, Louis Krupp <lkrupp_nos...@indra.com.invalid>
wrote:
>
> Well done!
>
> Louis
No such luck Louis....I thanked you for still standing for me.
I have just managed to get out of argument list mismatch. Still the
problem of synchronizing two subroutine persists

On 5/27/2010 4:19 AM, rudra wrote:
> On May 27, 11:21 am, Louis Krupp<lkrupp_nos...@indra.com.invalid>
> wrote:
>>
>> Well done!
>>
>> Louis
> No such luck Louis....I thanked you for still standing for me.
> I have just managed to get out of argument list mismatch. Still the
> problem of synchronizing two subroutine persists

So the program compiles and links with no errors, but doesn't run correctly?

Louis

On May 27, 5:38=A0pm, Louis Krupp <lkrupp_nos...@indra.com.invalid>
wrote:
>
> So the program compiles and links with no errors, but doesn't run correct=
ly?
>
> Louis

Actually, as i wrote in an earlier post, I have to split the code in
two part....this two part is not working correctly

On 5/27/2010 11:07 PM, rudra wrote:
> On May 27, 5:38 pm, Louis Krupp<lkrupp_nos...@indra.com.invalid>
> wrote:
>>
>> So the program compiles and links with no errors, but doesn't run correctly?
>>
>> Louis
>
> Actually, as i wrote in an earlier post, I have to split the code in
> two part....this two part is not working correctly

Are there any errors or warnings with which you'd like some help?

Louis