Uma vez montada a equa¸c˜ao do problema, fica a cargo da classe abstrata So- lution (Figura 5.4) resolvˆe-la. Esta classe estende a classe Observable, uma vez que ´e observada pela persistˆencia. Seu principal m´etodo ´e denominado execute() e ´e ele quem desencadeia todo o processo de solu¸c˜ao.
br.ufmg.dees.insane.solution pkg DynamicEquilibriumPath ModalVibration ModeSuperposition EquilibriumPath StaticEquilibriumPath NewmarkBeta Solution NonLinearNewmarkBeta <<interface>> DynamicNonLinearSolution WilsonTheta SteadyState DisplacementSuperposition DirectIntegration AccelerationSuperposition CentralDifference <<interface>> ModalSolution java.util.Observable
Figura 5.4: Diagrama de classe para Solution.
A classe SteadyState ´e a mais simples das subclasses de Solution, pois re- presenta a solu¸c˜ao de um problema linear est´atico. J´a a classe ModalVibration soluciona apenas o problema de autovalor de um modelo, obtendo suas freq¨uˆen- cias naturais de vibra¸c˜ao e seus respectivos modos. Estas duas classes possuem um objeto do tipo Assembler, que fornece as informa¸c˜oes acerca do modelo.
A classe abstrata EquilibriumPath generaliza uma solu¸c˜ao cujo objetivo ´e de- terminar uma trajet´oria de equil´ıbrio. Para o caso de uma an´alise n˜ao-linear est´atica, esta trajet´oria ´e geralmente representada em um gr´afico fator de carga x desloca- mento. Em uma an´alise dinˆamica, seja ela linear ou n˜ao, esta trajet´oria ´e obtida em fun¸c˜ao do tempo (gr´afico deslocamento x tempo).
A solu¸c˜ao n˜ao-linear est´atica ´e representada pela classe StaticEquilibrium- Path. Esta classe possui um objeto do tipo Step, que possui os m´etodos para resolu¸c˜ao do processo incremental iterativo, e uma lista de IterativeStrategy, in- formada pelo usu´ario, que define os m´etodos de controle para obten¸c˜ao da trajet´oria de equil´ıbrio a serem utilizados. StaticEquilibriumPath n˜ao possui um objeto do tipo Assembler, por´em possui o m´etodo setAssembler (Assembler) que atribui ao seu objeto Step um objeto Assembler para o qual deve resolver o processo iterativo. A classe abstrata DynamicEquilibriumPath generaliza as solu¸c˜oes de problemas dinˆamicos. Estes s˜ao subdivididos em dois tipos: ModeSuperposition e DirectIn- tegration, que representam as solu¸c˜oes por superposi¸c˜ao modal e por integra¸c˜ao direta, respectivamente. Os m´etodos de solu¸c˜ao de problemas dinˆamicos apresen- tados no cap´ıtulo 2 s˜ao representados pelas classes DisplacementSuperposition, AccelerationSuperposition, CentralDifference, NewmarkBeta (incluindo a va- ria¸c˜ao Hilber-α) e WilsonTheta.
A classe NonLinearNewmarkBeta estende NewmarkBeta, fazendo as modifica¸c˜oes necess´arias para que os efeitos n˜ao-lineares sejam considerados.
As interfaces ModalSolution e DynamicNonLinearSolution agrupam caracte- r´ısticas comuns a solu¸c˜oes pertencentes a ramos diferentes da heran¸ca de Solution, de forma a facilitar a persistˆencia de dados.
A figura 5.5 mostra o diagrama de classe para a interface Step, implementada pelas classes StandardNewtonRaphson, ModifiedNewtonRaphson e OrthogonalRe- sidueStandardNewtonRaphson. Estas classes implementam, respectivamente, os m´etodos incrementais iterativos de Newton-Raphson padr˜ao, modificado e padr˜ao
com res´ıduo ortogonal, e s˜ao utilizadas na an´alise n˜ao-linear est´atica. Na an´alise di- nˆamica n˜ao-linear, estes m´etodos s˜ao implementados internamente na solu¸c˜ao, pois n˜ao ´e necess´ario utilizar estrat´egias de itera¸c˜ao nestes casos.
br.ufmg.dees.insane.solution.step pkg br.ufmg.dees.insane.solution.step pkg + getIterativeStrategy() : IterativeStrategy + update() : void + getCurrentError() : double + execute() : void + getConvergence() : boolean
+ assignStepState(lambda : double) : void - convType : byte - convResult : boolean - tolerance : double - loadFactorTotal : double - currentError : double - currentIteration : int - numMaxIterations : int ModifiedNewtonRaphson + execute() : void
+ assignStepState(lambda : double) : void OrthogonalResidueStandardNewtonRaphson
+ update() : void + getCurrentError() : double + execute() : void
+ setIs(is : IterativeStrategy) : void + getConvergence() : boolean
+ assignStepState(lambda : double) : void - convType : byte - convResult : boolean - tolerance : double - loadFactorTotal : double - currentError : double - currentIteration : int - numMaxIterations : int StandardNewtonRaphson Step <<interface>> java.util.Observable java.util.Observable
Figura 5.5: Diagrama de classe para Step.
Estas trˆes classes tˆem todos os atributos necess´arios para obter a convergˆen- cia no passo, destacando-se um objeto Assembler, capaz de informar as matrizes e vetores da equa¸c˜ao a ser resolvida em cada itera¸c˜ao do passo; um objeto LinearE- quationSystem, capaz de resolver o sistema de equa¸c˜oes alg´ebricas lineares de cada itera¸c˜ao; e um objeto IterativeStrategy, que representa a estrat´egia de itera¸c˜ao corrente. Elas estendem a classe Observable, pois s˜ao observadas por StaticEqui- libriumPath.
A convergˆencia ´e verificada atrav´es dos m´etodos getConvergence() e setCon- vergence(). O m´etodo setConvergence(), quando invocado, cria um objeto Conver- gence, que, por meio do m´etodo checkConvergence(), calcula a convergˆencia baseada em for¸ca, deslocamento ou ambos, conforme informado pelo usu´ario.
br.ufmg.dees.insane.solution.iterativeStrategy
pkg
+ getStep() : Step + setStep(sp : Step) : void + getLambda() : double + setLoadFactor(lf : double) : void + getLoadFactor() : double + getCorrector() : double + getPredictor() : double <<interface>> IterativeStrategy UpdateOrthogonalArcLengthControl DisplacementControl - step 0..1 - step0..1 - step 0..1 - step0..1 0..1- step OrthogonalResidueControl ArcLengthControl WorkControl CilindricalArcLengthControl LoadControl GeneralizedDisplacementControl InitialOrthogonalArcLengthControl <<interface>> Step
Figura 5.6: Diagrama de classe para IterativeStrategy.
O diagrama de classe da interface IterativeStrategy ´e representado na fi- gura 5.6. Em sua hierarquia est˜ao as classes que representam os v´arios m´etodos de controle implementados por Fuina (2004): m´etodo de controle de carga, m´etodo de controle direto de deslocamento, m´etodo de controle por trabalho, m´etodo de controle de deslocamento generalizado, m´etodo de controle de res´ıduo ortogonal e m´etodo de controle de comprimento de arco e suas particulariza¸c˜oes. Cada uma destas classes possui os m´etodos getPredictor() e getCorrector() que calculam o fa- tor de carga da primeira e das demais itera¸c˜oes, respectivamente. `A exce¸c˜ao da classe LoadControl, todas as outras classes possuem um objeto do tipo Step, pois precisam deste para saber informa¸c˜oes sobre a itera¸c˜ao anterior durante o c´alculo do fator de carga.