1
Contexto del caso
Describe el objetivo y el entorno antes de pegar el error.
- Distribución y versión exactas
- Solver, régimen y modelos activos
- Sistema operativo y ejecución paralela
Comunidad y Resolución de Dudas
Foro de OpenFOAM en Español
Pregunta, comparte soluciones de CFD y colabora con ingenieros e investigadores de todo el mundo hispanohablante.
Categorías temáticas
Mostrando 5 temas de discusión
snappyHexMesh me destroza el borde de fuga y la no-ortogonalidad se va a 88º ayuda!!
Buenas gente, A ver si alguien me puede echar una mano porque llevo 2 dias pegandome con esto y me estoy volviendo loco. Estoy mallando un aleron de coche en OpenCFD v2412 con snappyHexMesh. La geometria esta exportada en STL limpia desde SolidWorks en milimetros. La caja de blockMesh tiene celdas de 10mm y todo guay en la fase de castellatedMesh. El problema viene en el snap: en las aristas vivas del borde de fuga me deforma las celdas un monton, mete un monton de skewness y cuando tiro el checkMesh me saca esto: text Checking geometry... Overall domain bounding box (-0.5 -0.5 -0.2) (1.5 0.5 0.2) Mesh (non-empty, non-wedge) directions (1 1 1) Mesh (non-empty, non-wedge) dimensions 3 All edges aligned with coordinate axes : no Total number of faces : 384192 Faces with non-orthogonality > 70 degrees : 1422 Faces with non-orthogonality > 80 degrees : 84 Maximum non-orthogonality = 88.42 degrees. Severe non-orthogonality error! Tengo el snapControls asi en el dict: text snapControls { nSmoothPatch 3; tolerance 2.0; nSolveIter 30; nRelaxIter 5; nFeatureSnapIter 10; explicitFeatureSnap true; implicitFeatureSnap false; } Alguien sabe que parametro tocar para que pille bien el borde afilado sin reventar la malla?? Gracias de antemano!! --- i7 13700K | 64GB RAM | Ubuntu 24.04 WSL2
#snappyHexMesh#calidad-malla#no-ortogonalidad#snapControls#surfaceFeatures
22
3
foam_novato_val(Ubuntu 24.04 (WSL2))
14 feb
FOAM FATAL IO ERROR: keyword boundaryField is undefined in dictionary 0/p
Buenas tardes comunidad, Llevo toda la tarde intentando arrancar una simulacion con simpleFoam tras importar una malla desde ANSYS con fluentMeshToFoam malla.msh y me salta este error en toda la cara al segundo 0: text --> FOAM FATAL IO ERROR: keyword boundaryField is undefined in dictionary "/home/diego/simulacion/0/p" file: /home/diego/simulacion/0/p from line 17 to line 22. From function const Foam::entry& Foam::dictionary::lookupEntry(const Foam::word&, bool, bool) const in file db/dictionary/dictionary.C at line 570. FOAM exiting He mirao el archivo 0/p 20 veces y juraria que esta bien escrito... que puede ser?? Os pego el archivo tal cual: text FoamFile { version 2.0; format ascii; class volScalarField; object p; } dimensions [0 2 -2 0 0 0 0]; internalField uniform 0 boundaryField { inlet { type zeroGradient; } outlet { type fixedValue; value uniform 0; } walls { type zeroGradient; } } A ver si alguien ve el fallo pq yo ya no veo nada jajaja. Gracias!
#FOAM-FATAL-IO-ERROR#boundaryField#0/p#fluentMeshToFoam#sintaxis
15
2
pimple_diego94(Ubuntu 22.04 LTS)
10 feb
Duda existencial: k-omega SST vs k-epsilon para aerodinamica externa con desprendimiento
Hola compas del foro, Estamos simulando en la facultad el $C_d$ de un furgon comercial a 120 km/h ($Re \approx 4.5 \times 10^6$) con simpleFoam. Empezamos con kEpsilon estandar porque convergia como una roca en 400 iteraciones, pero el $C_d$ nos esta dando como un 20% mas bajo de lo que marca el ensayo en tunel de viento. Hemos leido que k-epsilon sobreestima la viscosidad turbulenta en zonas de recirculacion trasera (la estela del porton) y retrasa el desprendimiento. ¿Vale la pena meterse en kOmegaSST? ¿Nos va a obligar a rehacer la malla para tener $y^+ \approx 1$ o con funciones de pared tipo omegaWallFunction tira bien con $y^+ \approx 30$? Gracias gente!!
#turbulencia#kOmegaSST#kEpsilon#yPlus#aerodinamica#Cd
31
4
foam_novato_val(Ubuntu 24.04)
5 feb
Floating point exception (core dumped) al paso t=0.002 en pimpleFoam
Buenas noches gente, Estoy corriendo un caso transitorio 2D de un cilindro en un canal con pimpleFoam y a las pocas iteraciones me explota con el temido: text Time = 0.002 Courant Number mean: 0.12 max: 4.82 diagonal: Solving for rho, Initial residual = 0, Final residual = 0, No Iterations 0 PBiCGStab: Solving for Ux, Initial residual = 0.0041, Final residual = 1.2e-06, No Iterations 2 PBiCGStab: Solving for Uy, Initial residual = 0.0089, Final residual = 3.1e-06, No Iterations 2 GAMG: Solving for p, Initial residual = 0.9841, Final residual = 0.0042, No Iterations 50 0 Foam::error::printStack(Foam::Ostream&) in "/usr/lib/openfoam/openfoam2412/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so" 1 Foam::sigFpe::sigHandler(int) in "/usr/lib/openfoam/openfoam2412/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so" 2 ? in "/lib/x86_64-linux-gnu/libc.so.6" 3 Foam::GAMGSolver::solve(Foam::Field<double>&, Foam::Field<double> const&, unsigned char) const [1] Floating point exception (core dumped) El paso temporal lo tengo en deltaT 0.001;. He probado a bajarlo a 0.0001 pero me sigue petando al cabo de unos pasos. Alguna idea de por donde empezar a mirar??
#Floating-Point-Exception#pimpleFoam#Courant#GAMG#divergencia
19
2
pimple_diego94(Ubuntu 24.04 LTS)
29 ene
setFields ejecuta sin error pero alpha.water sigue en 0 en ParaView (interFoam)
Hola a todos, Estoy montando una simulacion de llenado de tanque con interFoam en OpenFOAM 12. He configurado el system/setFieldsDict para meter una caja de agua de 1x1x1 m en el fondo: text defaultFieldValues ( volScalarFieldValue alpha.water 0 ); regions ( boxToCell { box (0 0 0) (1 1 1); fieldValues ( volScalarFieldValue alpha.water 1 ); } ); Ejecuto setFields y me dice que ha modificado 8000 celdas con exito: text Setting field default values Setting field region values Adding cells with centre within boxes 1((0 0 0) (1 1 1)) Setting volScalarFieldValue alpha.water = 1 End Pero luego abro paraFoam o arranco interFoam y el campo alpha.water esta completamente en 0 en todo el dominio! Que estoy haciendo mal?? Saludos desde Cordoba!
#setFields#interFoam#alpha.water#VOF#multifase
16
2
cfd_argentina(Ubuntu 24.04)
20 ene
Preguntas que se pueden resolver
Aporta contexto suficiente para que la comunidad pueda reproducir el problema
Una pregunta técnica eficaz reduce las suposiciones. El mensaje final del solver es importante, pero también lo son el instante en que aparece, los cambios recientes y la mínima configuración necesaria para provocarlo.
2
Evidencia mínima
Incluye texto copiable y fragmentos enfocados.
- Mensaje completo con líneas anteriores
- checkMesh y últimos residuales
- Diccionario relacionado, sin subir todo el caso
3
Pruebas realizadas
Explica qué descartaste y qué cambió.
- Última versión que funcionaba
- Una modificación por intento
- Resultado observado frente al esperado
Antes de publicar
Una secuencia corta para convertir la consulta en una decisión técnica trazable.
- 01Reproducir el fallo una vez más
- 02Reducirlo al cambio mínimo
- 03Copiar versión y comandos
- 04Adjuntar logs relevantes
- 05Formular una pregunta concreta
Consejo de campo: No sustituyas el error por una captura si puedes copiar el texto: así será indexable y otras personas podrán encontrar la solución.