Dear all,
maybe somebody with a little experience in usage of the PARDISO solver can help me out with this:
Reading the code in Linear_EQS::Solver(CNumerics* num), it seems to me that all parameters set for the PARDISO solver are hardcoded in OGS (except for no. of threads), and specification of the linear solver parameters (error_tolerance max_iterations precond) in *.num should have no effect on the solution, as PARDISO is a direct solver. Nevertheless, I see (small) differences in the solution when specifying different values for the error_tolerance. Is there a point I'm completely missing about the operation of PARDISO?
Bests, Christof
···
--
_______________________________________
Dr. Christof Beyer
Institute of Geosciences
Geohydromodelling
Christian-Albrechts-University Kiel
Ludewig-Meyn-Str. 10
24118 Kiel
Germany
phone: +49(0)431-8803172
fax: +49(0)431-8807606
mobile: +49(0)176-24297908
email: [email protected]
home: http://www.ifg.uni-kiel.de/
_______________________________________
hi Christof,
i sometimes use pardiso but have never noticed the behavior. as you wrote, a solver tolerance in num files should have no influence on PARDISO. there could be invalid memory access somewhere in the code... are you sure you set 805 as a solver type? otherwise, iterative solvers from lis will be used.
regards,
nori
···
On 22 July 2015 16:43:37 CEST, Christof Beyer <[email protected]> wrote:
Dear all,
maybe somebody with a little experience in usage of the PARDISO solver
can help me out with this:
Reading the code in Linear_EQS::Solver(CNumerics* num), it seems to me
that all parameters set for the PARDISO solver are hardcoded in OGS
(except for no. of threads), and specification of the linear solver
parameters (error_tolerance max_iterations precond) in *.num should
have
no effect on the solution, as PARDISO is a direct solver. Nevertheless,
I see (small) differences in the solution when specifying different
values for the error_tolerance. Is there a point I'm completely missing
about the operation of PARDISO?
Bests, Christof
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
Hi Nori,
yes, I'm sure the PARDISO solver is chosen, it is stated in the screen output from OGS. I do not see the differences in all my models, though. The problem I am trying to solve is quite big (2.3 mio grid cells) and has a time variant source term (defined by a rfd curve), for which again I have problems reproducing the correct numbers.
Christof
···
Am 22.07.2015 um 17:06 schrieb Norihiro Watanabe:
hi Christof,
i sometimes use pardiso but have never noticed the behavior. as you wrote, a solver tolerance in num files should have no influence on PARDISO. there could be invalid memory access somewhere in the code... are you sure you set 805 as a solver type? otherwise, iterative solvers from lis will be used.
regards,
nori
On 22 July 2015 16:43:37 CEST, Christof Beyer <[email protected]> wrote:
Dear all,
maybe somebody with a little experience in usage of the PARDISO solver
can help me out with this:
Reading the code in Linear_EQS::Solver(CNumerics* num), it seems to me
that all parameters set for the PARDISO solver are hardcoded in OGS
(except for no. of threads), and specification of the linear solver
parameters (error_tolerance max_iterations precond) in *.num should
have
no effect on the solution, as PARDISO is a direct solver. Nevertheless,
I see (small) differences in the solution when specifying different
values for the error_tolerance. Is there a point I'm completely missing
about the operation of PARDISO?
Bests, Christof
--
_______________________________________
Dr. Christof Beyer
Institute of Geosciences
Geohydromodelling
Christian-Albrechts-University Kiel
Ludewig-Meyn-Str. 10
24118 Kiel
Germany
phone: +49(0)431-8803172
fax: +49(0)431-8807606
mobile: +49(0)176-24297908
email: [email protected]
home: http://www.ifg.uni-kiel.de/
_______________________________________
just information for you. I tested trunk version withe PARDISO for a simple groundwater flow with different tolerance numbers but didn't see the problem. maybe the problem is specific to your problem setting or your environment. For example, deactivation of sub-domains doesn't work well with PARDISO.
Nori
···
On 22/07/15 17:37, Christof Beyer wrote:
Hi Nori,
yes, I'm sure the PARDISO solver is chosen, it is stated in the screen
output from OGS. I do not see the differences in all my models, though.
The problem I am trying to solve is quite big (2.3 mio grid cells) and
has a time variant source term (defined by a rfd curve), for which again
I have problems reproducing the correct numbers.
Christof
Am 22.07.2015 um 17:06 schrieb Norihiro Watanabe:
> hi Christof,
>
> i sometimes use pardiso but have never noticed the behavior. as you
> wrote, a solver tolerance in num files should have no influence on
> PARDISO. there could be invalid memory access somewhere in the code...
> are you sure you set 805 as a solver type? otherwise, iterative
> solvers from lis will be used.
>
> regards,
> nori
>
> On 22 July 2015 16:43:37 CEST, Christof Beyer <[email protected]> wrote:
>> Dear all,
>>
>> maybe somebody with a little experience in usage of the PARDISO solver
>> can help me out with this:
>>
>> Reading the code in Linear_EQS::Solver(CNumerics* num), it seems to me
>> that all parameters set for the PARDISO solver are hardcoded in OGS
>> (except for no. of threads), and specification of the linear solver
>> parameters (error_tolerance max_iterations precond) in *.num should
>> have
>> no effect on the solution, as PARDISO is a direct solver. Nevertheless,
>>
>> I see (small) differences in the solution when specifying different
>> values for the error_tolerance. Is there a point I'm completely missing
>>
>> about the operation of PARDISO?
>>
>> Bests, Christof
>
--
Norihiro Watanabe, Dr.-Ing.
Department of Environmental Informatics
Helmholtz-Zentrum für Umweltforschung GmbH - UFZ
Helmholtz Centre for Environmental Research GmbH - UFZ
Permoserstraße 15 / 04318 Leipzig / Germany
Telefon +49 341 235 1806
[email protected] / www.ufz.de
Sitz der Gesellschaft: Leipzig
Registergericht: Amtsgericht Leipzig, Handelsregister Nr. B 4703
Vorsitzender des Aufsichtsrats: MinDirig Wilfried Kraus
Wissenschaftlicher Geschäftsführer: Prof. Dr. Georg Teutsch
Administrativer Geschäftsführer: N.N.