assert output errors for demos

[js1019]

assert output errors for demos

[js1019]

Bringing to github our email communication. I asked:

we are interested in adding a validation phase that checks the output data

@js1019's answer:

I am not sure how to perform a validation. Are you suggesting a benchmark of some standard results from other platforms? The current output shows the relative errors. If the errors were small, ~10^-11, the users could be confident of their results

based on the above, I was wondering if we could add a script that automates these checks on the output log. We can work on a PR for adding this script, if you think this would be useful.

Yes, thanks, that will be great!

[j3soon]

Hi @js1019, regarding the relative errors:

The values of eigenfrequencies will be shown at the end of the computation as well as their relative errors, i.e., ||Ax-λBx||/||λ||, which is typically around 10^-13.

NormalModes/src/mod_pevsl.f90

Line 158 in 157d306

eigerr(J) = dsqrt(errd/real(mymatvec%Gpbsiz,8))/abs(EIGVAL(J))

I'm a bit confused about how the relative errors are calculated here. I thought the relative errors are calculated through the results of both poly. filter and shift-invert method? Like calculating the eigenvectors through shift-invert method and get result a, then calculate through poly. filter method and get result b. So the final relative error will be something like: |a-b|/a?

I didn't find the code performing shift-and-invert in this repo, so I'm wondering if the relative errors are calculated through other methods?

[js1019]

Hi @js1019, regarding the relative errors:

The values of eigenfrequencies will be shown at the end of the computation as well as their relative errors, i.e., ||Ax-λBx||/||λ||, which is typically around 10^-13.

NormalModes/src/mod_pevsl.f90

Line 158 in 157d306

eigerr(J) = dsqrt(errd/real(mymatvec%Gpbsiz,8))/abs(EIGVAL(J))

I'm a bit confused about how the relative errors are calculated here. I thought the relative errors are calculated through the results of both poly. filter and shift-invert method? Like calculating the eigenvectors through shift-invert method and get result a, then calculate through poly. filter method and get result b. So the final relative error will be something like: |a-b|/a?

I didn't find the code performing shift-and-invert in this repo, so I'm wondering if the relative errors are calculated through other methods?

@j3soon Good questions. Perhaps I need to make it more clear.

In the paper, we did report the relative errors while comparing two methods. However, in this repository, we provide the computational errors for each eigenpair (λ,x) obtained from the polynomial filtering method.

There are many reasons. The solutions of the shift-and-invert method are often not attainable, especially for large-scale problems. In many scenarios, unfortunately, such a comparison can't be performed since the proposed method/code is the only way we know to obtain the eigenpairs. (Several parallel algorithms are under development, we may have comparisons in the future.)
In addition, to include the shift-and-invert method, we need a parallel direct solver and another robust eigensolver as well. The I/O is different. Hence, I no longer maintain the code that performs the shift-and-invert method.

Instead, as long as the computational errors, i.e., ||Ax-λBx||/||λ||, are small, the solutions are expected to be accurate. This should hold true for other methods as well since there is no approximation at the matrix level.

I hope that this is clear. Please let me know if you have concerns.

[j3soon]

@js1019 Thanks for the clear explanation!
By the way, is the shift-and-invert code available? There's a section in the paper that compares the memory and time usages of the two methods. It would be much easier to validate with the shift-and-invert code provided.

[js1019]

@js1019 Thanks for the clear explanation!
By the way, is the shift-and-invert code available? There's a section in the paper that compares the memory and time usages of the two methods. It would be much easier to validate with the shift-and-invert code provided.

@j3soon Yes, I certainly agree. I had a separate code to do it but didn't make it publicly available. It is not quite straightforward to make it usable and well-documented since I've changed a lot over these years. This is not my current working priority but if it is required, I can find some time to provide it and let you know.

[j3soon]

@js1019 Yes, I believe that the shift-and-invert code is needed for comparing the two algorithms. Having some minimum documentation about the program requirements and the I/Os will be quite enough, I think.

[js1019]

Shift-and-invert code will not be maintained anymore as it can't even solve the actual problem with gravitational perturbation and rotation. The issue will be closed as there is no plan.