PARPACK: Initialize machine dependent constants only once in PDNAITR

[mmuetzel]

Pull request purpose

The current implementation checks the value of the variable aitr_first but sets first.

Detailed changes proposed in this pull request

Change that to set aitr_first to false after the initialization has run.

This also brings that part of the implementation of PDNAITR in line with the corresponding logic that is used in the implementation of the other P?NAITR.

[mergify]

Tick the box to add this pull request to the merge queue (same as @mergifyio queue).

• Queue this pull request

[fghoussen]

Looks relevant. Do this triggered problems at you r side?
Can you rebase?

[mmuetzel]

Thanks for reviewing.

No, I didn't see any actual problems.
We stumbled across that while checking if ElmerFEM could switch to ARPACK-ng. Currently, it is using an older version of the original ARPACK/PARPACK with some local changes for issues that have been found with that version. The developers wanted to make sure that the potential switch to ARPACK-ng wouldn't cause regressions when it comes to those local changes. (It wouldn't. So, ARPACK-ng is a good contender for ElmerFEM.)

While at that, I skimmed some of the source files of ARPACK-ng and came across this inconsistency.
Very likely, it isn't noticeable by any user of ARPACK-ng. At the worst, it currently causes a (very) slight slowdown when pdlamch10 is called when it isn't necessary. But calling that function isn't very costly afaict.
The current implementation looks like the intension was to avoid calling pdlamch10 repeatedly. The current behavior is probably just caused by a typo. (That interpretation is also supported by the fact that the implementations for the other P?NAITR set the "expected" variable.)

[fghoussen]

Very likely, it isn't noticeable by any user of ARPACK-ng.
looks like the intension was to avoid calling pdlamch10 repeatedly. The current behavior is probably just caused by a typo.

OK. Indeed, it sounds like what my first impressions were when grepping/reviewing the code.

[mmuetzel]

OK. Indeed, it sounds like what my first impressions were when grepping/reviewing the code.

So, do you agree that this can be merged as-is?

[fghoussen]

do you agree that this can be merged as-is?

I guess yes. Is the patch complete?

[mmuetzel]

Is the patch complete?

As far as I can tell, this one line change is all that is needed.
Do you think that more than that needs to change?

[fghoussen]

@mmuetzel: thanks!