Making fault

Dear Sebastian,

SUBROUTINE ElastoDyn.f90/COEFF() is only called once by ElastoDyn at initialization. Moreover, FAST does not allow parameter data types (p) to be changed after initialization.

Instead of changing p%BElmntMass(J,K) directly, I would search where this parameter is used in the time-domain part of the simulation and multiply it by a time-dependent scaling factor (e.g., 1.5).

Best regards,

Dear Jason,

I add a routine to ElastoDyn.f90 to perform the mass addition to blade elements as follows:

[code]!**********************************************************************************************************************************
!> This routine is used to add mass to blade elements at a given simulation time
SUBROUTINE AddMass(p, InputFileData, ErrStat, ErrMsg)
!..

  ! Passed variables

TYPE(ED_ParameterType), INTENT(INOUT) :: p !< Parameters of the structural dynamics module
TYPE(ED_InputFile), INTENT(IN) :: InputFileData !< all the data in the ElastoDyn input file
INTEGER(IntKi), INTENT(OUT) :: ErrStat !< Error status
CHARACTER(*), INTENT(OUT) :: ErrMsg !< Error message when ErrStat =/ ErrID_None

  ! Local variables.

INTEGER(IntKi) :: J ! Loops through nodes / elements.
INTEGER(IntKi) :: K ! Loops through blades.

     ! Initialize some output values
  ErrStat = ErrID_None
  ErrMsg  = ""

!..
! Calculate the new blade element mass
!..

DO K = 1,p%NumBl ! Loop through the blades

  DO J = 1,p%BldNodes    ! Loop through the blade nodes / elements


  ! Calculate the mass of the current element

     p%BElmntMass(J,K) = 1.5*p%MassB(K,J)*p%DRNodes(J)                        ! Mass of blade element J


  ENDDO ! J - Blade nodes / elements

ENDDO ! K - Blades

END SUBROUTINE AddMass
!----------------------------------------------------------------------------------------------------------------------------------
[/code]

and I call this Subroutine in FAST_Prog.f90 as follows:

[code]! Time Stepping:
!..

DO n_t_global = Restart_step, Turbine(1)%p_FAST%n_TMax_m1

  ! call AddMass routine at given simulation time 
  
  IF (n_t_global == 5) THEN
		CALL AddMass(p_ED, InputFileData, ErrStat, ErrMsg)
  END IF
  
  ! bjj: we have to make sure the n_TMax_m1 and n_ChkptTime are the same for all turbines or have some different logic here[/code]

now I’m trying to compile FAST.sln with VS but I’v got this error:

Error error #11023: Not all components required for linking are present on command line ipo
Severity Code Description Project File Line Suppression State
Error error LNK2019: unresolved external symbol ADDMASS referenced in function MAIN__ ipo_144887obj3.obj
Severity Code Description Project File Line Suppression State
Error fatal error LNK1120: 1 unresolved externals …..\build\bin\openfast_x64.exe

do you have any idea how to solve this error?

Best regards
Sebastian

Dear Sebastian,

All SUBROUTINES in ElastoDyn.f90 are PRIVATE by default (see the top section of MODULE ElastoDyn near the top of ElastoDyn.f90). You must make SUBROUTINE AddMass() PUBLIC if you wish to call it from FAST_Prog.f90, i.e., type the following before the CONTAINS statement:

PUBLIC :: AddMass

Best regards,

Dear Jason,

First of all thank you very much for your help. After changing the AddMass Subroutine to Public, I could compile FAST with VS without errors.
To check if the compiled .exe recognise the changes that I’ve done in ElastoDyn. I performed TEST 18 (5MW_Land_DLL_WTurb) for 10 s as TMax and with 0.01 as DT. But the results were not as expected. I couldn’t see any changes in the results at the given time (t=5 s).
untitled1.pdf (7.63 KB)
I couldn’t know if the problem comes from that all the parameters, which are related to Blade-Element-Mass (p%BElmntMass(J,K)), are only one time at the beginning of the simulation calculated and saved in Subroutine Coeff. So when I change the Blade-Element-Mass (p%BElmntMass(J,K)) at the middle of the simulation (at t=5 s) it does do the change but all other parameters will not change?
For this reason I modify the Subroutine AddMass, so it looks like Subroutine Coeff, but only p%BElmntMass(J,K) multiplied by 1.5 as below:

[code] ! Calculate the mass of the current element

     p%BElmntMass(J,K) = 1.5*p%MassB(K,J)*p%DRNodes(J)                        ! Mass of blade element J[/code]

After that I could compile FAST but Test 18 end with this error:

Can you tell me how to solve this error? Any help would be really appreciated.
Best regards,
Sebastian

Dear Sebastian,

I’m not sure I’m understand enough about what you are doing to comment why you are not getting the result you expect in one case and why the OpenFAST crashes in another case.

I did noticed from your earlier post that you call your new AddMass SUBROUTINE at n_t_global == 5. Please note that n_t_global is the time-step counter (an integer), not the actual simulation time (in seconds). So, you appear to be changing the ElastoDyn p%BElmntMass parameter soon after model initialization (5 time steps in).

Regarding your code change, it looks like your change to p%BElmntMass in AddMass is identical to the original change to p%BElmntMass in AddMass that you had posted on Jun 05.

Best regards,

Dear Jason,

Thank you for your quick response.
Regarding to the first part of my question: after the modifications in open FAST and ElstoDyn (see my post in Jun 05, 2019) I can’t see any changes in the results of TEST 18, the results were identical
Now I changed the time of calling of Suroutine AddMass to n_t_global == 500. In this case I expect a change in the results in actual simulation time of t = 5 s when TMax and DT in .fst file are set to 10 and 0.01 respectively. But the results still identical (see figure below).
untitled2.pdf (7.66 KB)
Regarding to the second part of my question: I tried to understand why the results are still the same. I expected that the parameters which are calculated in Subroutine Coeff are not changing at the given time (n_t_global == 500), because they are time-independent. For this reason I modified my AddMass Subrutine to recalculate all the parameters in Subroutine Coeff. So at the end my AddMass Subroutine looks like Subroutine Coeff with only one difference by calculation of blade-element-mass
p%BElmntMass(J,K) = 1.5*p%MassB(K,J)*p%DRNodes(J)

After that OpenFAST compiled without errors. But test 18 crashed as below:


Best regards
Sebastian

Dear Sebastian,

I think I understand what you are doing now.

I would guess OpenFAST is crashing in your second case because many calculations in SUBROUTINE Coeff() depend on data stored in the ElastoDyn input file, but that data is not known by the OpenFAST glue code (and the data does not exist after initialization anyway). You should not have InputFileData as an argument to your AddMass() SUBROUTINE.

I’m not sure why only changing p%BElmntMass(J,K) in SUBROUTINE AddMass() doesn’t affect your results, but it could be because the blade mass is stored in different ways (both as a mass per unit length, p%MassB(K,J), and as a mass per element, p%ElmntMass(J,K)). You’ll need to change both consistently for the result to be physical.

So, I would change your AddMass() SUBROUTINE to:

[code]!**********************************************************************************************************************************
!> This routine is used to add mass to blade elements at a given simulation time
SUBROUTINE AddMass(p)
!..

  ! Passed variables

TYPE(ED_ParameterType), INTENT(INOUT) :: p !< Parameters of the structural dynamics module

  ! Local variables.

INTEGER(IntKi) :: J ! Loops through nodes / elements.
INTEGER(IntKi) :: K ! Loops through blades.

!..
! Calculate the new blade element mass
!..

DO K = 1,p%NumBl ! Loop through the blades

  DO J = 1,p%BldNodes    ! Loop through the blade nodes / elements


  ! Calculate the mass of the current element

     p%MassB(K,J) = 1.5*p%MassB(K,J)
     p%BElmntMass(J,K) = p%MassB(K,J)*p%DRNodes(J)                        ! Mass of blade element J


  ENDDO ! J - Blade nodes / elements

ENDDO ! K - Blades

END SUBROUTINE AddMass
!----------------------------------------------------------------------------------------------------------------------------------[/code]
Does that give you the result that you expect?

Best regards,

Dear Jason,

Unfortunately, the change of both parameters (mass per unit length, p%MassB(K,J), and mass per element, p%ElmntMass(J,K)) doesn’t mad any changes in the result. The result still identical even when I used your cod in the previous post.
Actually I’ve two comprehension questions about the points that you described in the previous post:
First question: how does SUBROUTINE ED_CalcOutput calculate the outputs signals, when the data from SUBROUTINE Coeff does not exist after initialization?
Second question: Why OpenFAST glue code didn’t give me any error massage when I call p%BElmntMass during the simulation, although this parameter already doesn’t excite?

Thank you for your help
Best regards
Sebastian

Dear Sebastian,

The data in the ElastoDyn parameters type (p) is defined at initialization and remains stored throughout the entire simulation. It is the data from the input file (InputFileData) that does not exist after ElastoDyn initialization.

I would expect changing p%BElmntMass(J,K) and p%MassB(K,J) mid simulation would change the output. I would suggest stepping through the solution with the debugger that your AddMass() SUBROUTINE is being called properly and to ensure that the values of p%BElmntMass(J,K) and p%MassB(K,J) are indeed changed when they are used in ElastoDyn.

Best regards,

Dear Jason,

Actually I’m very new with VS. Can you provide me with more information about how to stepping through the solation with the debugger. I already generate an OpenFAST_Debug.exe file and I read the instructions for debugging with Visual Studio. But I still don’t know how to navigate the debug.exe to the 5MW_Land_DLL_WTurb.fst (test file) in VS. I used to run OpenFAST as explaned in issue #268 [url]https://github.com/OpenFAST/openfast/issues/268[/url] . The problem is when I run openfast_x64_Debug.exe in the command window the breakpoints in FAST_Prog.f90 were not recognized.

Thank you for your help
Best regards
Sebastian

Dear Sebastian,

I would recommend compiling in debug mode and stepping through the solution within VS by adding breakpoints, clicking on Step Into, etc. I’m sure you can find information on how to do this in VS help. You could also post specific questions on OpenFAST issues, where more of the OpenFAST developers are active than in this forum, which tends to cater more towards usage of FAST / OpenFAST.

Best regards,

For others following this forum thread, the discussion around Sebestian’s code changes has moved from here to OpenFAST issues: github.com/OpenFAST/openfast/issues/339.

Best regards,

Dear Jason,

I am trying to make faults on FAST; Blade fault and Gearbox Fault.
I have two questions:

  1. Blade Fault
    AdjBlMs, AdjFlSt and AdjEdSt are the factors that i can change.
    What is the difference between flap stiffness and edge stiffness?
    How can i change blade stiffness?
    Decrease the default value(=1) or increase?

  2. Gearbox Fault
    Can i “decrease” both Drivetrain torsional spring and Drivetrain torsional spring simultaneously for Gearbox Fault? Does it make sense?

Best Regards

Dear Hamridreza,

The flapwise direction is nominally normal to the chord and the edgewise direction is nominally parallel to the chord, so the flapwise stiffness is generally much less than the edgewise stiffness, except near the blade root. By “blade fault”, I would guess you mean cracks in the composite fibers, which I would expect would result in a reduction in stiffness.

I’m not sure how a “gearbox fault” would be related to the drivetrain torsional spring and damping. But I would say that normally the damping is proportional to the stiffness in some way, so, if you change the stiffness, it is likely good to the change the damping proportionally as well.

Best regards,

Dear Jason,
Thanks for your answer.
As you said for Blade crack simulation, i should reduce stiffness. I have a question:

For stiffness reduction, should i change both AdjFlSt = 1(Factor to adjust blade flap stiffness) and AdjEdSt = 1(Factor to adjust blade edge stiffness)?
or changing one of them is more appropriate for Blade crack?

Best Regards,

Dear Hamidreza,

I’m not an expert on that subject, but I would guess both the flapwise and edgewise stiffness would reduce as a result of cracks in the composite fibers.

Best regards,

Dear Jason,

I want to change the dynamics of the pitch system by varying the damping factor( 0.6) and the natural frequencies( 11 rad/s) from their nominal
values.
where can i find these parameters?

Best Regards,

Dear Hamidreza,

I’m assuming you are referring to the baseline controller for the NREL 5-MW wind turbine; is this correct? The baseline controller for the NREL 5-MW wind turbine is implemented as a dynamic library in Bladed format (DISCON.dll). The parameters are hard coded within this dynamic library. You can change them by opening up the corresponding source file (DISCON.f90), changing the parameters, and recompiling the dynamic library.

Best regards,

Dear Jason,

I have rigorously gone through each post in this series of blade stiffness changes in FAST. Can you tell me which subroutines of FAST v7 shall be helpful to make the required changes in the blade stiffness and modal coefficients? I believe the modular option isn’t available in FAST v7, which makes it difficult for me to understand, but indeed, the flexibility of the substructure load modeling in FAST v7 force me to use the earlier version. So, which subroutines and files shall I target to change the blade/tower stiffnesses in FAST v7?

Looking forward to hearing from you. Thanks.

Dear @Kashyap.Subham,

Given that the modal coefficients are parameters used to define the shape functions for the degrees of freedom, I would think they would be difficult to change throughout the simulation. But you could probably reasonable scale the blade stiffness throughout the simulation without updating the modal coefficients, at least for small stiffness scaling.

The blade elastic stiffness is stored as variable KBF in FAST v7. I would suggest applying scaling to KBF throughout the simulation within SUBROUTINE RtHS() of source file FAST.f90.

Best regards,