Openfast: Cambio dinámico de las propiedades de masa de la hoja dentro de una simulación dada en OpoenFAST y ElastoDyn

Una cosa que me parece extraña es que estás usando p_ED en FAST_Prog.f90. Esperaría que fuera Turbine(1)%ED%p . Si agregó un tipo p_ED usted mismo, ninguna de las variables se inicializaría, por lo que no pasará por los bucles o le dará fallas de segmentación.

Querida Bonnie,

Muchas gracias por tu rápida respuesta.
Agregué un tipo p_ED por mí mismo en el encabezado de FAST_prog.f90, porque pensé que el argumento en Fortran Subroutine funciona de la misma manera que en Matlab Function, pero obviamente parece que no.
Después de usar Turbine(1)%ED%p en FAST_Prog.f90 funcionó, pasó por los bucles y cambió la masa del elemento de la hoja.
Ahora estoy comprobando si las formas del modo de la hoja y la rigidez de la aleta y el borde también se cambian con el cambio de la masa del elemento de la hoja.
¿Podría dejar este problema abierto? Porque seguro que tendré más preguntas relacionadas con este tema en el futuro.

Atentamente
Laurence

Estimado @bjonkman ,

Desde la última publicación hice algunas modificaciones en el código fuente de ElstoDyn.f90, de modo que no solo se cambia la masa del elemento blade p%BElmntMass(J,K) dentro de la simulación, sino también todos los parámetros en SUBROUTINE Coeff(p,InputFileData, ErrStat, ErrMsg) . Para hacer eso, generé un SUBROUTINE UpdateCoeff(p, ErrStat, ErrMsg) , que eventualmente es una copia de Subrutina Coeff () con solo una diferencia: la Subrutina UpdateCoeff () no tiene Tipo de datos ED_InputFile , porque la Subrutina UpdateCoeff se llamaría dentro de la subrutina ED_CalcOutput en mitad de la simulación, mientras que InputFileData ya está destruido después de la inicialización. la llamada de la subrutina UpdateCoeff funciona de la siguiente manera:

SUBROUTINE ED_CalcOutput( t, u, p, x, xd, z, OtherState, y, m, ErrStat, ErrMsg )
!..................................................................................................................................
!...............................................................................................................................
   ! set the values in the AllOuts array:
   !...............................................................................................................................
      ! Define the output channel specifying the current simulation time:

   m%AllOuts(  Time) = REAL( t, ReKi )

      ! Change Blade Element Masses:

    IF ( t == 0.50 ) THEN

        p%MassB(K,J) = 1.5*p%MassB(K,J)

        ! start with recalculation of the Parameters in subroutine Ceoff()

        CALL UpdateCoeff(p, ErrStat, ErrMsg)

    END IF
! This part is done to generate the blade mass element SpnMb as an output to see if the masses changed or not, and it did work  
   DO K = 1,p%NumBl
      DO I = 1, p%NBlGages

                BlElmMass = p%BElmntMass(I,K)

        m%AllOuts(  SpnMb(I,K)) = REAL( BlElmMass, R8Ki)

      END DO !I
   END DO !K

Pero ahora, debido a que no hay ningún tipo de datos ED_Inputfile en la subrutina UpdateCoeff, generé nuevos parámetros p% para reemplazar InputFileData% en la subrutina Coeff y usarlos después en la subrutina UpdateCoeff de la siguiente manera:

SUBROUTINE Coeff(p,InputFileData, ErrStat, ErrMsg)
!..................................................................................................................................
   ELSE                    ! 3-blader
      p%Hubg1Iner = InputFileData%HubIner
      p%HubInerX = InputFileData%HubIner                ! Line 4799 where the 1st error occured 
      p%Hubg2Iner = 0.0
   ENDIF

! Calculate the tower shape functions (all derivatives):

      p%TwrFASF(1,J,2) = SHP( p%HNodesNorm(J), p%TwrFlexL, InputFileData%TwFAM1Sh(:), 2, ErrStat, ErrMsg )
      p%TwrFASF(2,J,2) = SHP( p%HNodesNorm(J), p%TwrFlexL, InputFileData%TwFAM2Sh(:), 2, ErrStat, ErrMsg )
      p%TwrFASF(1,J,1) = SHP( p%HNodesNorm(J), p%TwrFlexL, InputFileData%TwFAM1Sh(:), 1, ErrStat, ErrMsg )
      p%TwrFASF(2,J,1) = SHP( p%HNodesNorm(J), p%TwrFlexL, InputFileData%TwFAM2Sh(:), 1, ErrStat, ErrMsg )
      p%TwrFASF(1,J,0) = SHP( p%HNodesNorm(J), p%TwrFlexL, InputFileData%TwFAM1Sh(:), 0, ErrStat, ErrMsg )
      p%TwrFASF(2,J,0) = SHP( p%HNodesNorm(J), p%TwrFlexL, InputFileData%TwFAM2Sh(:), 0, ErrStat, ErrMsg )

      p%TwFAM1ShX(:) = InputFileData%TwFAM1Sh(:)     ! Line 5195 where the 2nd error occured 
      p%TwFAM2ShX(:) = InputFileData%TwFAM2Sh(:)

END SUBROUTINE Coeff

!**********************************************************************************************************************************

   SUBROUTINE UpdateCoeff(p, ErrStat, ErrMsg)
!..................................................................................................................................
    ELSE                    ! 3-blader
      p%Hubg1Iner = p%HubInerX
      p%Hubg2Iner = 0.0
   ENDIF

      ! Calculate the tower shape functions (all derivatives):

      p%TwrFASF(1,J,2) = SHP( p%HNodesNorm(J), p%TwrFlexL, p%TwFAM1ShX(:), 2, ErrStat, ErrMsg )

Hice eso para todos los InputFileData% en Subroutine Coeff (), y también asigné el nuevo parámetro definido en SetOtherParameters () como sigue:

SUBROUTINE SetOtherParameters( p, InputFileData, ErrStat, ErrMsg )
!..................................................................................................................................
  CALL AllocAry(p%TwFAM1ShX,  PolyOrd,          'TwFAM1ShX' , ErrStat, ErrMsg ); IF ( ErrStat /= ErrID_None ) RETURN

Pero cuando empiezo a compilar me sale este error:

Creo que tal vez sea incorrecta mi defensa de los nuevos parámetros.
Espero poder explicar el problema y me complacería que me ayudaran a resolver este error.

Atentamente
Laurence

PD: tomé solo algunas secciones del código completo de cada subrutina para ilustrar el problema

Una cosa a tener en cuenta es que si está cambiando algún archivo de entrada del registro, es posible que deba compilar dos veces (la primera vez que Visual Studio regenera los archivos * _Types.f90, pero el código que depende de esos tipos de archivos no necesariamente compilar con la versión correcta del archivo * _Types.f90 hasta la segunda compilación). Esa puede ser la causa del primer error que muestra (a menos que algo más sea incorrecto).

Un problema que veo es que su matriz p%TwFAM1SHX no parece tener el mismo tamaño que la matriz InputFileData%TwFAM1Sh . Debe asignarlos para que tengan el mismo tamaño si los va a igualar entre sí. Aquí está la asignación que veo para la matriz existente:

CALL AllocAry  ( InputFileData%TwFAM1Sh,  PolyOrd-1, 'TwFAM1Sh'  , ErrStat, ErrMsg )

El suyo está destinado a ser un elemento más grande.

Si está utilizando la rama dev actual, el proceso de compilación de los archivos _Types.f90 ha cambiado: ya no forman parte del proceso de compilación estándar. En su lugar, vea esto: https://raf-openfast.readthedocs.io/en/feature-registry_rework/source/dev/types_files.html~~

editar: vea el comentario de @rafmudaf a continuación para ver el enlace.

En realidad, este es un enlace mejor a los documentos: https://openfast.readthedocs.io/en/dev/source/dev/types_files.html.

Estimado desarrollador de OpenFAST:
@jjonkman
@bjonkman
Podría cambiar la masa de los elementos de la hoja dentro de la simulación y me gustaría discutir con usted el resultado de la adición de masa.
Aumenté la masa de los elementos de la pala multiplicando la densidad de masa de cada elemento de la pala por un factor de 1,5. La adición masiva procedió como parte de la Subrutina ED-CalcOutput llamando a la Subrutina UpdateCoeff en un tiempo de simulación dado (en mi ejemplo en t = 0.5 [s]). Adjunté el archivo ElastoDyn.f90 para ver todas las modificaciones en mi código.

ElastoDyn.txt

Después de compilar OpenFAST, realicé la Prueba 18 (5MW_Land_DLL_WTurb) y tracé las masas de los elementos de la hoja para la Lista de nodos de la hoja que tienen galgas extensiométricas BldGagNd en la figura uno, estas señales (SpnMb) las generé yo mismo para ver la adición de masa física. En la figura 2 comparé la velocidad del rotor de cada versión de OpenFAST y de la función OpenFAST + AddMass.

Figura_1.pdf

Figura_2.pdf

En realidad, expié una reducción continua de la velocidad del rotor después de una adición de masa de 1,5 para cada elemento de la pala, ¡pero las cifras no mostraron eso!
¿Es correcta mi expectativa? ¿Mi implementación de la adición masiva fue correcta?

Atentamente
Laurence

@jjonkman @bjonkman
Una pregunta más, me gustaría expandir el archivo de entrada ElastoDyn.dat para usar el factor creciente
_AddMassF_ y Time _AddMassT_ para la adición masiva como InputData, por lo que no tengo que compilar OpenFAST cada vez que necesito cambiar la hora o el factor de adición masiva:

Ya agregué esos datos de entrada y sus parámetros correspondientes en ElastoDyn_Registry.txt y en ElastoDyn_IO.f90.
Después de eso, podría compilar OpenFAST, pero cuando comienzo una simulación, aparece este error:

¿Está seguro de que está leyendo correctamente las dos nuevas entradas del archivo? Agregó dos líneas nuevas CALL ReadVar() y las puso después del espacio donde dice PtfmYIner ?

Hola,

¿Es posible utilizar señales de ServoDyn en ElstoDyn? Veo que hay señales generadas en ElastoDyn para usar en ServoDyn así:
''
! ................................................. .................................................. ............................
! Salidas necesarias para ServoDyn
! ................................................. .................................................. ............................

y% Yaw = x% QT (DOF_Yaw)
y% YawRate = x% QDT (DOF_Yaw)
y% YawAngle = x% QT (DOF_Yaw) + x% QT (DOF_Y)! aproximación bruta para el error de guiñada ... (sin restarlo de la dirección del viento)
y% BlPitch = u% BlPitchCom! OtherState% BlPitch
y% LSS_Spd = x% QDT (DOF_GeAz)
y% HSS_Spd = ABS (p% GBRatio) * x% QDT (DOF_GeAz)
y% RotSpeed ​​= x% QDT (DOF_GeAz) + x% QDT (DOF_DrTr)

Now I’m trying to do exact the opposite. I want to generate a signal in ServoDyn to use it in ElasoDyn.
To do that I defined first an output signal 
`y%BlPitchED(K) = p%BlPitchF(K)`
Then I allocated this signal in SrvD_OutputType data structure (y)

CALL AllocAry (y% BlPitchED, p% NumBl, 'BlPitchED', ErrStat2, ErrMsg2)
LLAMAR CheckError (ErrStat2, ErrMsg2)
IF (ErrStat> = AbortErrLev) RETURN
`` Afterthat I defended this output in ServoDyn_Registry.txt typedef ^ OutputType ReKi BlPitchED {:} - - "Ángulos de paso de la hoja comandados (ElastoDyn)" radianes`
¿Pero ahora no sé qué debo hacer para usar esta señal en ElstoDyn?
Gracias por tu ayuda

Estimado @LaurenceWETI ,

En el marco de modularización FAST / OpenFAST, cuando los módulos están acoplados, las entradas y salidas deben ser consistentes, es decir, las entradas a un módulo dado deben ser derivadas de las salidas de otros módulos. Por lo tanto, si desea agregar una salida a ServoDyn que se convierta en una entrada a ElastoDyn, debe definir la salida en ServoDyn, definir la entrada en ElastoDyn y luego modificar el código de pegamento de OpenFAST para transferir la salida de ServoDyn como una entrada a ElastoDyn. Por ejemplo, vea cómo la salida BlPitchCom de ServoDyn se transfiere como entrada a ElastoDyn.

Atentamente,

@jjonkman gracias por su rápida respuesta