¿Su solicitud de función está relacionada con un problema?
Describe la solución que te gustaría
Describe las alternativas que has considerado
¿Estaría interesado en tener dicha funcionalidad o es demasiado molesto? Si esto parece una buena idea, estoy muy dispuesto a trabajar en su desarrollo, pero mis habilidades son muy limitadas y necesito ayuda. O consejos sobre por dónde empezar.
Ahora estoy leyendo el hanbook del programador.
Atentamente
Bartosz Stachowicz>
Contexto adicional
<--->
Estimado @bartoszstachowicz ,
Buena pregunta. La incapacidad de visualizar las líneas de amarre es una limitación lamentable de la capacidad de visualización actual de OpenFAST. Y no solo para MAP ++, sino también para los demás módulos de amarre de OpenFAST: MoorDyn y FEAMooring. Solo algunos comentarios:
Las líneas de amarre no se visualizan actualmente porque los módulos de amarre actualmente interactúan con otros módulos solo a través de sus conexiones pasacables (para la interacción amarre-subestructura), por lo que el código de pegamento OpenFAST no conoce el desplazamiento y la carga de puntos a lo largo de cada línea de amarre.
Para agregar la capacidad de visualización, probablemente sería mejor agregar una salida de los módulos de amarre relacionada con el desplazamiento de los nodos a lo largo de cada línea de amarre (incluso si esta salida no tiene una interacción asociada con otros módulos). Se debe utilizar una malla de línea 2 para garantizar que la funcionalidad de visualización pueda interpretar la interconexión entre los elementos puntuales.
MAP ++ resuelve analíticamente cada línea de amarre, por lo que cada línea no está discretizada numéricamente (por supuesto, hay nodos en las interconexiones entre cada línea de amarre). Esto puede dificultar la visualización de la forma de la catenaria de cada línea en MAP ++, a menos que los nodos se agreguen artificialmente a la solución. MoorDyn y FEAMooring implican la discretización de cada línea de amarre en múltiples segmentos de línea.
Dejaré que otros comenten cuánto esfuerzo sería desarrollar esta nueva funcionalidad.
Atentamente,
Estimado equipo de OpenFAST,
Lo intenté este fin de semana y funciona. En MAP C ++ ya existe una rutina para evaluar las coordenadas de un número determinado de puntos a lo largo de la línea: map_plot_x_array
Tuve que modificar las salidas, crear una sola malla para todas las líneas en la simulación y las entradas iniciales para poder establecer la longitud del elemento.
Sin embargo, hay un cambio en los nodos de conexión, en la dirección x de la línea local, cuando se traza. Espero que esto solo sea cierto para la rutina de trazado :).
¿Quizás alguien sepa por qué es esto? No podía resolver esto todavía.
Adjunto algunas fotos del turno.
Saludos cordiales,
BS
@bartoszstachowicz , ¡Esa es una muy buena adición! No estoy del todo seguro de por qué hay un cambio en la dirección x de los cables. Tendría que mirar su implementación para saber si es un artefacto de la exportación VTK o un error en MAP ++.
¿Es esta función algo que le gustaría contribuir a la comunidad OpenFAST? Si es así, ¿le gustaría crear una solicitud de extracción a la rama de desarrollo con la adición de su código?
@ andrew-platt, Hola, sí, claro, tan pronto como tenga un momento para ordenarlo un poco y aprender cómo funciona esto con las solicitudes de extracción.
Comentario más útil
Estimado equipo de OpenFAST,
Lo intenté este fin de semana y funciona. En MAP C ++ ya existe una rutina para evaluar las coordenadas de un número determinado de puntos a lo largo de la línea: map_plot_x_array
Tuve que modificar las salidas, crear una sola malla para todas las líneas en la simulación y las entradas iniciales para poder establecer la longitud del elemento.
Sin embargo, hay un cambio en los nodos de conexión, en la dirección x de la línea local, cuando se traza. Espero que esto solo sea cierto para la rutina de trazado :).
¿Quizás alguien sepa por qué es esto? No podía resolver esto todavía.
Adjunto algunas fotos del turno.
Saludos cordiales,
BS