Belos solvers ignore (almost) all orthogonalization parameters

[jjellio]

Currently, solvers that need an orthogonalizer call an orthomanager's constructor with only a label argument. (called from the SolMgr's setParameter routine) This allows one to change the type of orthogonalization, but never configure it. There are no methods for setting or obtaining the solver's orthogonalizer through the SolMgr interface, hence there is no way to control orthogonalization parameters even though they are supported.

A solution consistent with Trilinos' current packages would be to allow solvers to accept an optional parameter sublist called 'Orthogonalization' that would contain optional parameters for the underlying orthogonalizer. Belos SolMgr implementations would then need to pass this list (if it exists) to the orthomanager constructors.

This is a bit more nuanced than simply adding the above logic, because ortho parameters have leaked into certain SolMgr implementations (GMRES/BlockGMRES, etc..) A small refactor would be required, forcing the solMgr to query the orthomanager instance for necessary parameters at the solver level. This will result in some modifications to certain SolMgr constructors.

@trilinos/belos

[mhoemmen]

Belos::PseudoBlockGmresSolMgr takes an "Orthogonalization Constant" parameter. However, it only delivers that parameter to its OrthoManager if the OrthoManager is "DGKS".

We have nested ParameterLists now (didn't 10+ years ago, if I remember right), so we could add an "Orthogonalization Parameters" sublist that goes straight into the OrthoManager. @hkthorn , would that make sense?

[hkthorn]

Yes, that is because the "Orthogonalization Constant" is only pertinent to DGKS, it is used to determine whether another step of classical Gram Schmidt is necessary. The other methods have a static number of iterations they perform (ICGS, IMGS perform 2). Each solver should tell you which orthogonalization routine they are using, which is stored in the internal parameter list that can be accessed using getCurrentParameters(). I see that the solvers are not storing that information in the internal parameter list ... hmm that used to be stored in there. That can be fixed easily.

I'm not sure what the nested parameter list would be for, are the orthogonalization routines going to be more parametrized than they are now?

I've been watching the traffic, is there a logical issue where an orthogonalization type is being requested through the parameter list and ignored? If it is just the case that the "Orthogonalization Constant" is ignored, except in the case of DGKS, that can be understood now.

What am I missing?

Thanks, Heidi

--

Heidi K. Thornquist Electrical Models & Simulation Sandia National Laboratories Albuquerque, NM 87185-1323

From: Mark Hoemmen notifications@github.com<mailto:notifications@github.com> Reply-To: trilinos/Trilinos reply@reply.github.com<mailto:reply@reply.github.com> Date: Thursday, January 5, 2017 at 6:03 PM To: trilinos/Trilinos Trilinos@noreply.github.com<mailto:Trilinos@noreply.github.com> Cc: "Thornquist, Heidi K" hkthorn@sandia.gov<mailto:hkthorn@sandia.gov>, Mention mention@noreply.github.com<mailto:mention@noreply.github.com> Subject: [EXTERNAL] Re: [trilinos/Trilinos] Belos solver constructors ignore orthomanager paramerlist options (#965)

Belos::PseudoBlockGmresSolMgr takes an "Orthogonalization Constant" parameter. However, it only delivers that parameter to its OrthoManager if the OrthoManager is "DGKS".

We have nested ParameterLists now (didn't 10+ years ago, if I remember right), so we could add an "Orthogonalization Parameters" sublist that goes straight into the OrthoManager. @hkthornhttps://github.com/hkthorn , would that make sense?

- You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/trilinos/Trilinos/issues/965#issuecomment-270803653, or mute the threadhttps://github.com/notifications/unsubscribe-auth/APLX1pHEEukQ2SbCR6zYrps1hMSb8A5hks5rPZL8gaJpZM4LaBtD.

[jjellio]

I simply bumped into this. There are many codes that set the orthogonalization to ICGS and then attempt to configure the number of iterations. There is actually no way to change this setting (with a Belos Solver). With ICGS you get 2 passes. It is not an issue for me. Looking at the various ortho kernels, they all support various settings, but in practice no one can change them from the defaults.

[mhoemmen]

This is relevant to @tjfulle 's benchmarking work (link not accessible to public): https://gitlab-ex.sandia.gov/tjfulle/BelosPerformanceEval/issues/3

[mhoemmen]

Note that ICGS has a parameter for the number of orthogonalization passes. It's 2 by default.

[hkthorn]

I've been doing some minor cleanup in the solver managers and looking over the orthomanagers and the later-developed orthomanager factory. The solver managers do a lot of work to generate the correct orthogonalization method, especially when that method has changed in between calls to setParameters. While the orthomanager factory provides a nicer parameter list interface to the orthogonalization methods, there appears some cleanup there too. The processing of the parameters is not always consistent with what is done in the solver managers. The solver managers will validate the incoming parameters, but do not change any unspecified parameters back to the defaults. So, a user only has to specify what they want to change in the solver and can expect everything else to remain the same as it was the last time setParameters was called. Also, given that approach at parameter list processing, it would be nice if the orthogonalization managers could return their currentParameters so that the solver managers could maintain their current parameter list. It looks mostly possible through the ParameterListAcceptorDefaultBase, just not complete.

As a brief note, GCRODR[single vector and block] and MINRES do not handle their parameters in the same way. However, GCRODR already uses the orthomanager factory and MINRES does not need one. Any solver manager refactor to address orthogonalization will not include those solver implementations.

[mhoemmen]

@hkthorn That sounds right. There was a time when we were on a kick to make everything implement ParameterListAcceptor, so that Optika could drive the whole stack. That was back during the whole "standard interface for things that take ParameterList" debate circa 2011. Whether an input ParameterList should represent a delta (like Belos) or a current state (unspecified parameters take default values) was part of that debate.

[hkthorn]

@mhoemmen Thanks for the input! I just wanted to document my findings just in case I needed to be corrected.

[github-actions[bot]]

This issue has had no activity for 365 days and is marked for closure. It will be closed after an additional 30 days of inactivity. If you would like to keep this issue open please add a comment and/or remove the MARKED_FOR_CLOSURE label. If this issue should be kept open even with no activity beyond the time limits you can add the label DO_NOT_AUTOCLOSE. If it is ok for this issue to be closed, feel free to go ahead and close it. Please do not add any comments or change any labels or otherwise touch this issue unless your intention is to reset the inactivity counter for an additional year.

[mhoemmen]

@jennloe @jjellio @jhux2 @csiefer2 it feels like the responsible thing not to let this issue autoclose

[hkthorn]

Progress has been made on this issue by @jennloe, so we should check where it's at now.

[jennloe]

This isssue is not yet resolved. I think when I last worked on it, I had updated all the orthogonalization managers so they could accept the needed parameters. But I hadn't yet converted the solver manager interface to pass those parameters through.

[mhoemmen]

@jennloe FYI, the automatic backlog issue deleter has closed a lot of issues that I'm sure never got resolved. It might pay to go through issues that have been closed over the past year and a half. I don't have the permissions to add the "please don't autoclose" label and it's not for me to decide any more, but I just wanted to let y'all know that the autocloser has been busy : - ) .