[Carlos Ivorra]

No entiendo cuando dices "y no se puede dar un valor  de resultado final a esa integral" si Carlos ha mostrado que vale \( -1 \). ¿En qué parte de su razonamiento crees que ha fallado para que esa integral NO tenga que valer \( -1 \)?

Ahí DCM ha dicho, sin que sirva de precedente, algo con sentido: los dos cálculos prueban que la integral no existe:

  1)    Esta integral Carlos demostró que no cumple el Teorema de Rubini, y  por lo tanto no es integrable y no se puede dar un valor  de resultado final a esa integral.

     En cambio la integral que  yo he propuesto en este hilo  es de una función continua, definida en un intervalo, sólo que en un extremo del intervalo la función diverge. Debido a que la función es continua,  el teorema de Rubini  se cumple y no ocurre como el caso de la  función que ha propuesto Carlos.

Lo que no entiende DCM es la integral que él ha propuesto en este hilo. No es una integral definida en un intervalo. La integral que determina el campo gravitatorio de una esfera es una integral sobre la esfera. DCM pretende reducirla (aunque no entienda lo que hace) a una integral sobre un anillo seguida de una integral sobre un intervalo. Cuando hace eso, no está aplicando el teorema de Rubini porque no existe (he ahí una muestra de su nivel), no está aplicando el teorema de Fubini porque no se puede aplicar (el integrando no es integrable sobre la esfera), sino que aplica el único teorema al que se puede aferrar en un caso así: el teorema de (Harry) Houdini.

Yo le he calculado la integral sobre la esfera con otra falsa aplicación de Fubini y sale un resultado infinito. Tenemos así dos cálculos de su integral, una da un valor finito y otra infinito. Pero DCM se aferra al teorema de Houdini y dice que la que no da lo que él quiere no vale.

También le mostré, siguiendo una observación de Masacroso, que la integral en módulo da infinito, lo cual ya prueba que la función no es integrable en la esfera, pero DCM se aferró a Houdini y se escaqueó diciendo que la integral en módulo no tiene significado físico. Que, con significado físico o no, pruebe que la integral que quiere calcular no existe, le dio igual.

En cuanto a lo del infinito sin límites como vía de escape... como dijo Jan Hus en la hoguera al ver a los que contemplaban cómo le quemaban vivo:  O sancta simplicitas! (¡Oh, santa ingenuidad!)

[DaniM]

Hola a todos. ¡Ya tenemos simulador! Con su panel de control y todo.  Lo he subido aquí para que podáis jugar con él:

https://force-field-particles-simulator.vercel.app/



Aquí está el código fuente:

https://github.com/danielthetechie/force-field-particles-simulator/tree/main/src

Los ficheros más relevantes (donde está contenida la física del programa) son Universe.js y Particle.js.

También es apta para tierrahuequistas como nuestro amigo DCM, ya que se puede configurar para que la distancia inicial de todas las partículas con respecto del origen sea igual al radio del universo (como en el gif de arriba), esto es, que no haya partículas en el interior de la esfera. El único inconveniente es que no tiene un final feliz para DCM, sino que el final es el que predijo Richard unos cuantos mensajes más atrás:

Con la suficiente cantidad de tiempo quedará una sola partícula, pero que sin importar el número inicial de estas nunca se forma una estructura hueca, así funciona la naturaleza

Explico algunas opciones que quizá no sean demasiado claras al principio:

- Constante de fuerza: por defecto es \( -1 \), con signo negativo para crear una fuerza de atracción, pero se puede poner positivo para que la fuerza sea de repulsión. A más magnitud, más intensa será la fuerza, ya sea en un sentido u otro. Si la constante es \( 0 \) y la velocidad inicial de las partículas también la dejáis a \( 0 \), pues... nada, pasamos a un universo aburrido y estático.

- Las opciones con un % se calculan con respecto al valor máximo de la opción de arriba. Por ejemplo, si el radio del universo es \( 600 \) unidades y se escoge como distancia mínima al centro el valor \( 50 \), no es que sean 50 unidades, sino que es el \( 50\% \) de \( 600 \), es decir, \( 300 \) unidades. (Esto lo hice así para evitar que se pueda elegir valores mínimos superiores a los máximos y evitar errores.)

- La opción "Aumentar tamaño de las partículas compuestas" se refiere a que cuando dos partículas chocan (el choque siempre es inelástico, no hay rebotes), si ésta está activada el radio de la partícula resultante aumenta (lo hace de forma un poco artificial, eso sí, y lo hace sumando un 10% del radio de la partícula más pequeña al radio de la partícula más grande). Si desactiváis la opción, el radio de la partícula resultante será igual al de la partícula más grande antes del choque, y como efecto secundario veréis órbitas que duran más tiempo antes de que las partículas se absorban entre ellas.

- En la info de abajo, la "velocidad media del sistema" se refiere al cálculo de hacer el promedio de las velocidades instantáneas de todas las partículas en todos sus ejes. Es una manera de medir la evolución del sistema: al final del todo, la velocidad de la partícula que queda acaba siendo constante. Y si elegís que la constante de fuerza sea positiva (o sea, que la fuerza sea repulsiva), veréis que al cabo de un rato la velocidad media del sistema se va estabilizando a medida que las partículas se van alejando y disminuye la fuerza entre ellas.

- Para mover la cámara, mantened el botón derecho del ratón apretado y ésta rotará. Para desplazaros, lo mismo pero con click izquierdo. Para aumentar o disminuir el zoom, usad la rueda del ratón.

- Al inicio todas las partículas son rojas, pero cuando chocan, las partículas resultantes son de color verde para distinguirlas mejor de las originales.

Ahora respondo a Richard en particular:

Primero que nada  gracias , estoy muy contento con que la idea haya colado y te haya motivado a programarlo.

Gracias a ti por el algoritmo.  De hecho, si te parece bien, me gustaría hacerte una mención de agradecimiento en el futuro Readme del proyecto. Le quiero añadir una opción para cambiar de idioma, algunas opciones más, pulir cosas y compartirlo con más gente.

Además ...Wow, quien pudiera jugar con cosas así, he hecho cosas más pobres visualmente, pero cuando lo pusiste  a rotar en el espacio e hiciste zoom, quedé alucinado.

He usado una librería de Javascript llamada Three, que es para hacer gráficos en 3D, no es difícil de aprender y seguro que tú como ingeniero podrías sacarle mucho más provecho que yo. 

hay como una concentración de partículas al centro que puede ser a causa de la perspectiva o a la propia distribución aleatoria que por tener mas espesor la esfera en el centro habrá mas partículas sobre esa línea de visión, por las dudas revisa si esta bien la aleatoriedad.

Al final lo he intentado solucionar de dos maneras:

1) Reemplazando la función por defecto para generar números aleatorios por una criptográfica que se supone que añade más aleatoriedad (en el fichero math.js puedes ver la función getRandomNumber original, que la he dejado comentada, por su reemplazo, inmediatamente más abajo).

2) Añadiendo la opción "distancia mínima al centro del universo" explicada más arriba.

no se si será la escala pero veo grandes en tamaño a las partículas respecto del diámetro de la esfera contenedora,  agrandar \( R \) o bajar \( r_i \)  sería un consejo, pero quizá se pierda definición cuando todo se aglomere en el centro a lo largo del tiempo

Sí, creo que en el primer GIF que mostré usé un radio bastante pequeño (quizá 100 o 200 unidades, ahora no recuerdo), pero ahora se puede ajustar hasta las 3000 unidades. Si quieres más, dímelo.

La idea de fondo de la simulación funciona bien cuando el número de partículas $$n$$ es muy elevado para un $$R$$ grande, pero se ralentiza el cálculo entre posición y posición, además se tarda mas en aglutinar  todo, si aumentas n quizá te convenga primero calcular todas la posiciones para cada tiempo, guardarlas en una base de datos y luego solo ejecuta la parte visual, donde se ven las trayectorias usando los datos y no calculándolos en el mismo  tiempo de ejecución...

Es una manera ingeniosa, pero no sé hasta qué punto viable desde el punto de vista de la memoria, ya que habría que guardar una matriz de números bastante tocha en la base de datos para cada frame que durara la animación, y a cada ejecución del programa con diferentes parámetros quizá habría que esperar un rato hasta tener la base de datos repoblada. Aunque es cierto que una vez hecho esto, podrías correr la animación con un \( n \) mucho más alto de manera fluida.

Ahora mismo los cálculos se realizan a cada frame, se asignan los resultados a las variables de las partículas, se desplazan de forma acorde con dichos valores y vuelta a empezar en el siguiente frame. Según he leído en la documentación de la librería, no se procede a la animación del siguiente frame hasta que no estén todos los cálculos terminados.

En mi ordenador (que no es gran cosa, un laptop con un procesador Intel i3 6006U), la animación va fluida hasta los \( 600 \) - \( 700 \) partículas, a partir de ahí ya empieza a sufrir. Pero eso solo pasa al principio, ya que a medida que se van produciendo los choques y las partículas se van uniendo, voy borrando todas las referencias de las partículas iniciales para liberar memoria, así que aunque se empiece con un número relativamente alto de partículas, la animación acabará siendo más fluida con el tiempo.

El número máximo de partículas lo he limitado a \( 1000 \), pero otra vez, si quieres más dímelo y lo subo. 

Se podría comenzar la simulación dándole una velocidad, dirección y sentido inicial a cada partícula

Esto ya se puede ajustar también en las opciones.  Por defecto las partículas empiezan sin velocidad, pero se puede ajustar.

por cierto habría que poder visualizar un corte de la esfera en un determinado momento, para ver si es hueca o no... quizá sea mucho pedir

Si te refieres a parar la animación en un determinado momento, es fácil de hacer. Pronto le pondré un botón para poder pausar la animación y que se pueda mover la cámara para poder ver con detalle el estado del universo en un determinado momento.

por más evidencia que presentes el fanatismo será superior

Sí, hay que admitir que contra un fanático que quiere serlo no hay nada que hacer desde la razón, pero programar esto y leer el hilo ha sido divertido: una cosa no quita la otra. 

Siento la tardanza, por temas de trabajo no he podido dedicarle tanto tiempo estos días.

[sugata]

Como se dice en españa: "¡¡¡VAYA CURRO!!!"

[Richard R Richard]

Hola a todos. ¡Ya tenemos simulador! Con su panel de control y todo.  Lo he subido aquí para que podáis jugar con él:

https://force-field-particles-simulator.vercel.app/



Aquí está el código fuente:

https://github.com/danielthetechie/force-field-particles-simulator/tree/main/src

Los ficheros más relevantes (donde está contenida la física del programa) son Universe.js y Particle.js.

Fascinante!!!!   Te felicito, hermoso, sumamente instructivo, fácil de operar, en unas cuantas pruebas he visto cosas que requieren tiempo de explicación para los alumnos, órbitas elípticas, velocidad de escape, en fin, muy, pero muy bien logrado.

También es apta para tierrahuequistas como nuestro amigo DCM, ya que se puede configurar para que la distancia inicial de todas las partículas con respecto del origen sea igual al radio del universo (como en el gif de arriba), esto es, que no haya partículas en el interior de la esfera. El único inconveniente es que no tiene un final feliz para DCM, sino que el final es el que predijo Richard unos cuantos mensajes más atrás:

Con la suficiente cantidad de tiempo quedará una sola partícula, pero que sin importar el número inicial de estas nunca se forma una estructura hueca, así funciona la naturaleza

Yo no le veo mayores inconvenientes ni los tendrá  si lo haces mas complejo aún al punto que el terrahuequista de turno te lo solicite de buenas formas, pero para mi es suficientemente claro, pero hemos visto que siempre descalifica innecesariamente así que esperemos su reacción.

Explico algunas opciones que quizá no sean demasiado claras al principio:

- Constante de fuerza: por defecto es \( -1 \), con signo negativo para crear una fuerza de atracción, pero se puede poner positivo para que la fuerza sea de repulsión. A más magnitud, más intensa será la fuerza, ya sea en un sentido u otro. Si la constante es \( 0 \) y la velocidad inicial de las partículas también la dejáis a \( 0 \), pues... nada, pasamos a un universo aburrido y estático.

- Las opciones con un % se calculan con respecto al valor máximo de la opción de arriba. Por ejemplo, si el radio del universo es \( 600 \) unidades y se escoge como distancia mínima al centro el valor \( 50 \), no es que sean 50 unidades, sino que es el \( 50\% \) de \( 600 \), es decir, \( 300 \) unidades. (Esto lo hice así para evitar que se pueda elegir valores mínimos superiores a los máximos y evitar errores.)

- La opción "Aumentar tamaño de las partículas compuestas" se refiere a que cuando dos partículas chocan (el choque siempre es inelástico, no hay rebotes),

Te entiendo tambien he intentado hacer un simulador de la cinemática de choques de moléculas de gases ideales en un recipiente, para graficar la distrbución de boltzmann en el tiempo y programar el choque en 3d elástico no es tarea fácil, no imposible, pero muy laborioso conceptualmente traducir a 3d la física.

Edito: estuve jugando un rato y veo que las orbitas elipticas cuando el problema es en dos cuerpos (quedan dos partículas: no  funciona como debería, voy a revisar el código para ver por qué, ya que simula muy bien para ser un error grosero, quiza se deba al corte numérico del computo, pero es bastante apreciable en ese caso.)

si ésta está activada el radio de la partícula resultante aumenta (lo hace de forma un poco artificial, eso sí, y lo hace sumando un 10% del radio de la partícula más pequeña al radio de la partícula más grande). Si desactiváis la opción, el radio de la partícula resultante será igual al de la partícula más grande antes del choque, y como efecto secundario veréis órbitas que duran más tiempo antes de que las partículas se absorban entre ellas.

Si es notable, espero que no sea motivo de crítica por parte de DCM ,
como aporte a la mejora simplemente en el choque podrías elegir que la masa final es la suma de las masas individuales, y el volumen aditivo

El radio final entre las partículas i y j creando una nueva k sería $$m_k=m_i+m_j$$ y  $$r_k=\sqrt[3]{r_i^3+r_j^3}$$ aqui estaríamos despreciando el modulo de compresibilidad si fueran gases y el efecto sobre el volumen que hace la presión interna creada por la gravedad sobre cada partícula individual.

En efecto es que la aglomeración mas lenta provoca orbitas mas largas  y la visualización de la conservación del momento angular al aglomerarse primero en una forma de disco y luego terminando en una esfera central rotante, que por ahora no se aprecia bien,  quizá la crítica constructiva pase en que no se observa rotar a la esfera central ni cambiar el eje de ese giro con cada impacto.. no se si es mucho pedir para un proyecto que ya cumple su cometido.

Te lo pongo si te interesa

  para programar

Esto es al momento de impacto se puede definir un centro de masas CM  reutilizando parte de lo dicho

si $$dij<ri+rj$$  las partículas están en contacto, su ponemos un choque inelástico donde

$$xk=\dfrac{mi\cdot xi+mj\cdot xj}{mi+mj}$$
$$yk=\dfrac{mi\cdot yi+mj\cdot yj}{mi+mj}$$
$$zk=\dfrac{mi\cdot zi+mj\cdot zj}{mi+mj}$$

$$vxk=\dfrac{mi\cdot vxi+mj\cdot vxj}{mi+mj}$$
$$vyk=\dfrac{mi\cdot vyi+mj\cdot vyj}{mi+mj}$$
$$vzk=\dfrac{mi\cdot vzi+mj\cdot vzj}{mi+mj}$$

puedes definir la posición y  velocidad relativa al centro de masas como 


$$xrkix=xi-xk$$
$$xrkiy=yi-yk$$
$$xrkiz=zi-zk$$


$$vrkix=vxi-vxk$$
$$vrkiy=vyi-vyk$$
$$vrkiz=vzi-vzk$$


el momento angular como $$\vec L=mi\begin{vmatrix} \vec x & \vec y & \vec z \\ xi-xk &yi-yk & zi-zk \\  vxi-vxk & vyi-vyk & vzi-vzk\end{vmatrix}+mj\begin{vmatrix} \vec x & \vec y & \vec z \\ xj-xk &yj-yk & zj-zk \\  vxj-vxk & vyj-vyk & vzj-vzk\end{vmatrix}$$

puedes hallar si no me equivoco , la frecuencia de rotación sabiendo que $$|L|=I\omega^2$$ y que el momento de inercia de la esfera es $$I=\dfrac{2}{5}mr^2$$ de lo cual la frecuencia angular de giro $$\omega$$ es calculable.

no cometes error al sumar vectorialmente los momentos angulares de las propias masas antes de chocar con el calculado del propio choque, $$\vec Lk=\vec L+\vec {Li}+\vec {Lj} $$ pero que pasa esto te trae mas calculo solo en el momento de cada choque , luego la magnitud se conserva hasta el siguiente choque.
no se cuan dificil es renderizar que cada esfera verde  rota sobre un eje con velocidad angular $$\omega$$, ya te digo no es mi proyecto ni pretendo complicarlo solo indicarte donde posiblemente se aleje de la realidad y te marquen una crítica al modelo.

[/q][/q][/q][/q][/q][/q][/q]

[cerrar]

- En la info de abajo, la "velocidad media del sistema" se refiere al cálculo de hacer el promedio de las velocidades instantáneas de todas las partículas en todos sus ejes. Es una manera de medir la evolución del sistema: al final del todo, la velocidad de la partícula que queda acaba siendo constante. Y si elegís que la constante de fuerza sea positiva (o sea, que la fuerza sea repulsiva), veréis que al cabo de un rato la velocidad media del sistema se va estabilizando a medida que las partículas se van alejando y disminuye la fuerza entre ellas.

Entiendo que quieres lograr, en definitiva lo que se estabiliza en un valor mínimo es la energía cinetica de todo el sistema. calculado como $$E=\sum\limits_{i=1}^{n}\dfrac 12m_i|vi|^2+\dfrac 12 I_i|\omega_i |^2$$  si los choques fueran elasticos esto sería una constante (me olvido que varia el potencial gravitatorio y no es cierto) que indicaría que tu modelo funciona bien, pero aqui los choques inelásticos deben provocar que E vaya en descenso con cada nueva aglomeración impacto...

Pero esto es independiente de lo que DCM piensa que con el tiempo la gravedad de lo que hay al interior  por ser inferior a lo que cre es la gravedad superficial entonces se nucleara en una superficie y no en una esfera solida, pero se olvida que la otra superficie al otro lado de la esfera es atraída por la superfice primera y todo se comprime sin forma una capa superficial.

Primero que nada  gracias , estoy muy contento con que la idea haya colado y te haya motivado a programarlo.

Gracias a ti por el algoritmo.  De hecho, si te parece bien, me gustaría hacerte una mención de agradecimiento en el futuro Readme del proyecto. Le quiero añadir una opción para cambiar de idioma, algunas opciones más, pulir cosas y compartirlo con más gente.

El merito es tuyo, haz lo que quieras con el programa, sería un honor que me menciones, por otro lado no me molestaría que te tomes todo el crédito, no he dicho nada que no esté escrito en ningún otro lado.

Además ...Wow, quien pudiera jugar con cosas así, he hecho cosas más pobres visualmente, pero cuando lo pusiste  a rotar en el espacio e hiciste zoom, quedé alucinado.

He usado una librería de Javascript llamada Three, que es para hacer gráficos en 3D, no es difícil de aprender y seguro que tú como ingeniero podrías sacarle mucho más provecho que yo. 

Una vez que le había encontrado el gustito a python.. pero bueno javascripst solo debería desempolvarlo con alguna lectura rápida, para luego intentar algo basico y luego intentar complejidad, desde ya muchas gracias por la información, veré que puedo hacer, con el poco tiempo que tengo, muchas veces lo uso para ayudar por aqui y allá.

hay como una concentración de partículas al centro que puede ser a causa de la perspectiva o a la propia distribución aleatoria que por tener mas espesor la esfera en el centro habrá mas partículas sobre esa línea de visión, por las dudas revisa si esta bien la aleatoriedad.

Al final lo he intentado solucionar de dos maneras:

1) Reemplazando la función por defecto para generar números aleatorios por una criptográfica que se supone que añade más aleatoriedad (en el fichero math.js puedes ver la función getRandomNumber original, que la he dejado comentada, por su reemplazo, inmediatamente más abajo).

2) Añadiendo la opción "distancia mínima al centro del universo" explicada más arriba.

no se si será la escala pero veo grandes en tamaño a las partículas respecto del diámetro de la esfera contenedora,  agrandar \( R \) o bajar \( r_i \)  sería un consejo, pero quizá se pierda definición cuando todo se aglomere en el centro a lo largo del tiempo

Sí, creo que en el primer GIF que mostré usé un radio bastante pequeño (quizá 100 o 200 unidades, ahora no recuerdo), pero ahora se puede ajustar hasta las 3000 unidades. Si quieres más, dímelo.
Reitero es tu proyecto, se ve excelente , mejorado respecto del primero, yo ya alucino con lo que veo, como todo, una vez que lo exploras se observa que es perfectible, pero así esta mas que bien.

La idea de fondo de la simulación funciona bien cuando el número de partículas $$n$$ es muy elevado para un $$R$$ grande, pero se ralentiza el cálculo entre posición y posición, además se tarda mas en aglutinar  todo, si aumentas n quizá te convenga primero calcular todas la posiciones para cada tiempo, guardarlas en una base de datos y luego solo ejecuta la parte visual, donde se ven las trayectorias usando los datos y no calculándolos en el mismo  tiempo de ejecución...

Es una manera ingeniosa, pero no sé hasta qué punto viable desde el punto de vista de la memoria, ya que habría que guardar una matriz de números bastante tocha en la base de datos para cada frame que durara la animación, y a cada ejecución del programa con diferentes parámetros quizá habría que esperar un rato hasta tener la base de datos repoblada. Aunque es cierto que una vez hecho esto, podrías correr la animación con un \( n \) mucho más alto de manera fluida.

Ahora mismo los cálculos se realizan a cada frame, se asignan los resultados a las variables de las partículas, se desplazan de forma acorde con dichos valores y vuelta a empezar en el siguiente frame. Según he leído en la documentación de la librería, no se procede a la animación del siguiente frame hasta que no estén todos los cálculos terminados.

Si, toma solo lo que creas positivo, tu eres el que sabe como será mejor, quizá mi punto de vista lo desmejore en vez de hacerlo veloz.

En mi ordenador (que no es gran cosa, un laptop con un procesador Intel i3 6006U), la animación va fluida hasta los \( 600 \) - \( 700 \) partículas, a partir de ahí ya empieza a sufrir. Pero eso solo pasa al principio, ya que a medida que se van produciendo los choques y las partículas se van uniendo, voy borrando todas las referencias de las partículas iniciales para liberar memoria, así que aunque se empiece con un número relativamente alto de partículas, la animación acabará siendo más fluida con el tiempo.

yo no tengo ventajas graficas en mi PC pero lo veo de mil maravillas, simplemente un lujo.

El número máximo de partículas lo he limitado a \( 1000 \), pero otra vez, si quieres más dímelo y lo subo. 

Se podría comenzar la simulación dándole una velocidad, dirección y sentido inicial a cada partícula

Esto ya se puede ajustar también en las opciones.  Por defecto las partículas empiezan sin velocidad, pero se puede ajustar.

Si el limite no lo deseas subir no será mi queja ni mi solicitud, será del terrahuequista, así que si quieres  explora el máximo numero sin perder continuidad en la grafica renderizada.
Y sí, con velocidad inicial se lo ve mas dinámico, y aunque no es muy factible que se den equilibrios como la formación de satélites o planetas porque se requerirían $$n$$ muy pero muy grande y tiempos grandes ,  ni cercanos a los propios a los de la naturaleza, he visto que se nuclean en mas de una esfera y rotan entre sí, así que solo creo que puede ser necesario pulir que el tamaño no crezca tan rápidamente.

por cierto habría que poder visualizar un corte de la esfera en un determinado momento, para ver si es hueca o no... quizá sea mucho pedir

Si te refieres a parar la animación en un determinado momento, es fácil de hacer. Pronto le pondré un botón para poder pausar la animación y que se pueda mover la cámara para poder ver con detalle el estado del universo en un determinado momento.

por más evidencia que presentes el fanatismo será superior

Sí, hay que admitir que contra un fanático que quiere serlo no hay nada que hacer desde la razón, pero programar esto y leer el hilo ha sido divertido: una cosa no quita la otra. 

Siento la tardanza, por temas de trabajo no he podido dedicarle tanto tiempo estos días.

No importa lo que se tarde, la calidad de lo que presentaste es inmejorable, lo que me refería al corte es que como presentas la forma visual de la esfera sólida externa, te dirá que quiere ver como es por dentro, pero es claro que por la forma de la modelización estamos tomando el interior de la esfera lo asumimos relleno, y esto nos traerá nuevas criticas, pero no hay nada que en primera medida no podamos modelizar para rebatir con datos sus argumentos. el tema es que la nucleación no provoca un cascarón.

Pd. cuando tengas tiempo  dime cual es la idea detrás de getLengthOfN3DVectorsSum

Observa lo siguiente  si pones 2 partículas en el universo con velocidades iniciales aleatorias, mientras no escapen, es decir que su velocidad relativa sea menor que $$v<\sqrt{\dfrac{2G(M+m)}{R}}$$ lo mas probable es que se orbiten indefinidamente, no que choquen, pero veo muy propenso al sistema a que provoque colisiones, quizá sea porque no se puede elegir correctamente los rango de velocidades o quizá la densidad en muy variable pero no debería influir. Fijate si puedes poner un comando para que la densidad no sea tan aleatoria ya que en la naturaleza no lo es,  hay una proporción muy definida de densidades y que elementos hay presentes en un sistema de partículas real, ejemplo en la tierra el material mas abundante es el hierro de densidad 7.8  en proporciones como       
 Hierro (34,6%).        Oxigeno (29,5%).        Silicio (15,2%).        Magnesio (12,7%).  Pero por lo general el oxigeno se presenta como óxidos de hierro silicio y magnesio cuyas densidades no son las de los propios elementos, además  poco hay en estado gaseoso en la atmósfera, y el hidrogeno lo tenemos en el agua de lo mares que no suman en porcentaje, el oxigeno gaseoso  que existe  es gracias a que ciertos microorganismos liberaron suficiente cantidad a la atmósfera y hoy  son los arboles que evolucionaron con la fotosíntesis la principal fuente de reposición, sino no estaríamos por aqui. 


https://es.wikipedia.org/wiki/Estructura_de_la_Tierra

A que voy , he revisado el código no es muy  difícil de seguir y no veo errores en math.js pero no logro ver que se produzcan orbitas estables, que es lo mas común que debe ocurrir, así que se me ocurre que puede estar el error en el truncamiento de los números  calculados, con que precisión los trabajas?

[manooooh]

Hola

Hola a todos. ¡Ya tenemos simulador! Con su panel de control y todo.  Lo he subido aquí para que podáis jugar con él:

https://force-field-particles-simulator.vercel.app/

¡Felicidades por el programa!

Quería hacer una pequeña sugerencia: Me gusta mucho que al pasar el cursor sobre las opciones del Panel de control se cambie a Horizontal resize, pero me gustaría que se pueda cambiar el valor con la rueda del mouse. Quizás de manera /10 para cada valor porque tienen mínimos y máximos diferentes (así, para pasar de 0% a 100% haya que hacer como máximo 10 scroll up con la rueda); o bien hacerlo más básico e ir modificando de a 1 unidad, ya que no hay decimales. O quizás haya algo más elegante.

Saludos

[DaniM]

Hola, muchas gracias a todos por vuestras buenas palabras y el feedback. 

me gustaría que se pueda cambiar el valor con la rueda del mouse. Quizás de manera /10 para cada valor porque tienen mínimos y máximos diferentes (así, para pasar de 0% a 100% haya que hacer como máximo 10 scroll up con la rueda); o bien hacerlo más básico e ir modificando de a 1 unidad, ya que no hay decimales. O quizás haya algo más elegante.

Tienes razón, cambiar los valores con la rueda del ratón sería mucho más cómodo que ir arrastrando todo el tiempo. Me lo apunto para implementar.

Observa lo siguiente si pones 2 partículas en el universo con velocidades iniciales aleatorias, mientras no escapen, es decir que su velocidad relativa sea menor que $$v<\sqrt{\dfrac{2G(M+m)}{R}}$$ lo mas probable es que se orbiten indefinidamente, no que choquen, pero veo muy propenso al sistema a que provoque colisiones

Voy a responderte a todo con más calma en otro momento, pero por hacerte una consulta rápida, ¿es posible que esto ocurra porque la constante de fuerza que usamos es demasiado grande en valor absoluto? Al final, en la naturaleza \( G \approx 6.67 \cdot{} 10^{-11} \) y aquí estamos usando el valor mínimo de \( G = -1 \).

He hecho cuatro pruebas y en dos de ellas las partículas se orbitan durante un rato antes de chocar, ¿quizá la fuerza de atracción sea demasiado alta?

https://streamable.com/b8nvor?src=player-page-share

He probado a usar \( G = -0.01 \), pero no he tenido paciencia para esperar a ver si chocan o no porque entonces todo va desesperadamente lento. 😅

En caso de que la velocidad inicial sea cero, las dos partículas van a chocarse del tirón, pero entiendo que esto es normal, ¿no? Teniendo en cuenta que se pueden unir por una línea recta y que la fuerza de gravedad es radial...

no logro ver que se produzcan orbitas estables, que es lo mas común que debe ocurrir, así que se me ocurre que puede estar el error en el truncamiento de los números  calculados, con que precisión los trabajas?

Los cálculos sobre las variables de las partículas se hacen con 15 dígitos decimales. Te pongo un pantallazo sobre el estado de una partícula en un determinado momento del programa:



Muchas gracias otra vez por tus observaciones y te responderé a lo demás en cuanto pueda. 

PD:

como aporte a la mejora simplemente en el choque podrías elegir que la masa final es la suma de las masas individuales, y el volumen aditivo
El radio final entre las partículas i y j creando una nueva k sería $$m_k=m_i+m_j$$ y  $$r_k=\sqrt[3]{r_i^3+r_j^3}$$

Genial, implementaré el radio final como has indicado, pero solo quería confirmar que la suma de masas ya se está haciendo (ver línea 154 de Universe.js, subrayada en azul):

[Richard R Richard]

Hola , no había pensado en el valor de la constante G como causa de los choques, pero puede ser, el tema es que si G es grande las órbitas elípticas se aplanan, esto hace que su períastro, la distancia más corta entre masas en la órbita sea menor que la suma de sus radios con mayor frecuencia, he visto software que lo evita, pero nunca con tantas masas como lo has hecho tu , es formidable, además de rápido.
Si usamos valores reales deberíamos esperar tiempos reales, voy a pensar la escala a la que funcione bien a tiempo real de ejecución, que todo suceda en 5 min hasta 1 hora me parece lógico.
La otra posibilidad es que el terreno de juego sea pequeño respecto de las masas, esto en la física real haría es que todas tiendan al centro y no a nuclearese por sectores y a orbitarse.
Quizá si G es menor lo que debes subir es Delta el tiempo entre paso y paso, pensaré una relación para que se vea igual de rápido que ahora que esta muy bien con -1 en G.


Si la velocidad inicial es cero dos partículas chocan inexorablemente, pero si no lo es deben orbitarse, hay una velocidad mínima para evitarse  y una máxima para escaparse y alejarse indefinidamente.

Sï, la suma de masa está bien calculada.

[DCM]

No entiendo cuando dices "y no se puede dar un valor  de resultado final a esa integral" si Carlos ha mostrado que vale \( -1 \). ¿En qué parte de su razonamiento crees que ha fallado para que esa integral NO tenga que valer \( -1 \)?

Ahí DCM ha dicho, sin que sirva de precedente, algo con sentido: los dos cálculos prueban que la integral no existe:

  1)    Esta integral Carlos demostró que no cumple el Teorema de Rubini, y  por lo tanto no es integrable y no se puede dar un valor  de resultado final a esa integral.

     En cambio la integral que  yo he propuesto en este hilo  es de una función continua, definida en un intervalo, sólo que en un extremo del intervalo la función diverge. Debido a que la función es continua,  el teorema de Rubini  se cumple y no ocurre como el caso de la  función que ha propuesto Carlos.

Lo que no entiende DCM es la integral que él ha propuesto en este hilo. No es una integral definida en un intervalo. La integral que determina el campo gravitatorio de una esfera es una integral sobre la esfera. DCM pretende reducirla (aunque no entienda lo que hace) a una integral sobre un anillo seguida de una integral sobre un intervalo. Cuando hace eso, no está aplicando el teorema de Rubini porque no existe (he ahí una muestra de su nivel), no está aplicando el teorema de Fubini porque no se puede aplicar (el integrando no es integrable sobre la esfera), sino que aplica el único teorema al que se puede aferrar en un caso así: el teorema de (Harry) Houdini.

Yo le he calculado la integral sobre la esfera con otra falsa aplicación de Fubini y sale un resultado infinito. Tenemos así dos cálculos de su integral, una da un valor finito y otra infinito. Pero DCM se aferra al teorema de Houdini y dice que la que no da lo que él quiere no vale.

También le mostré, siguiendo una observación de Masacroso, que la integral en módulo da infinito, lo cual ya prueba que la función no es integrable en la esfera, pero DCM se aferró a Houdini y se escaqueó diciendo que la integral en módulo no tiene significado físico. Que, con significado físico o no, pruebe que la integral que quiere calcular no existe, le dio igual.

En cuanto a lo del infinito sin límites como vía de escape... como dijo Jan Hus en la hoguera al ver a los que contemplaban cómo le quemaban vivo:  O sancta simplicitas! (¡Oh, santa ingenuidad!)

Para contestarte es necesario recordar lo que escribiste en este mensaje     https://foro.rinconmatematico.com/index.php?topic=123119.msg512525#msg512525 
y lo que que yo te constesté en mi mensaje siguiente      https://foro.rinconmatematico.com/index.php?topic=123119.msg512983#msg512983

  Como bien dijiste:

   Por definición, la intensidad del campo gravitatorio de una esfera hueca \( S \) de densidad (superficial) \( \rho \) en un punto \( \vec P \) es

\( \displaystyle \vec E = \int_S\frac{ G\rho}{\|\vec x-\vec P\|^3}(\vec x-\vec P)\,d\sigma \).

 Parametrizando la esfera como superficie de revolución del arco \( (Rx, R\sqrt{1-x^2}) \), es decir, mediante la carta:

\( \vec X(x, \theta) = (Rx, R\sqrt{1-x^2}\cos \theta, R\sqrt{1-x^2}\sen \theta),\qquad (x, \theta)\in [-1, 1]\times [0, 2\pi] \)

Entonces, el elemento de superficie es \( d\sigma = R^2dx\,d\theta \) y, considerando el punto \( \vec P = (R, 0, 0) \), calculando rutinariamente obtenemos que

\( \|\vec X-\vec P\|^2 = 2R^2(1-x) \).

  Con estas ecuaciones podemos ver que:

\( \vec E = \int_S\frac{ G\rho R^2}{\|\vec x-\vec P\|^3}(\vec x-\vec P)\,d\sigma=\int_{(x, \theta)\in [-1, 1]\times [0, 2\pi]}  \frac{ G\rho R^2}{ (2R^2(1-x))^{3/2}}((R(x-1) \vec i + R\sqrt{1-x^2}\cos \theta \vec j+ R\sqrt{1-x^2}\sen \theta\vec k))\ dx d\theta= \vec Ex +\vec Ey+\vec Ez \)

  Con lo cual la integral en la superficie de la esfera ya se ha transformada en una integral doble de la variable x y \( \theta \).

   Puedes ver que el integrando es una función continua en todo el recinto de integración, sólo que en x=1 el integrando diverge, por ello lo que hay que hacer es calcular esta integral como una integral  impropia de Riemann de 2ª especie, es decir

\( \vec E =  Lim_{\varepsilon -->1^-}\int_{(x, \theta)\in [-1, \epsilon]\times [0, 2\pi]}  \frac{ G\rho R^2}{ (2R^2(1-x))^{3/2}}((R(x-1) \vec i + R\sqrt{1-x^2}\cos \theta \vec j+ R\sqrt{1-x^2}\sen \theta\vec k))\ dx d\theta \)

   En  un mensaje anterior ya te demostré que  \( \vec Ey =\vec Ez = 0 \)  en contra con lo que tú decías que divergía. Espero que esto está claro.

  Por lo tanto  el campo total gravitatorio  sólo tiene componente en el eje X.

\( \vec E =  Lim_{\varepsilon -->1^-}\int_{(x, \theta)\in [-1, \epsilon]\times [0, 2\pi]}  \frac{ G\rho R^2}{ (2R^2(1-x))^{3/2}}((R(x-1) \vec i ))\ dx d\theta \)

\( \vec E =  Lim_{\varepsilon -->1^-} \int_{-1}^\epsilon \int_0^{2\pi} \frac{ G\rho R^2}{ (2R^2(1-x))^{3/2}}((R(x-1) \vec i ))\ dx d\theta \)

\( \vec E =  Lim_{\varepsilon -->1^-}\frac{G \rho}{8^{1/2}} \int_{-1}^\epsilon \int_0^{2\pi} \frac{ 1}{ (x-1)} \vec i \ dx d\theta \)

  Y como podéis observar la función a integrar da lo mismo integrar primero la variable \( \theta \)  que la variable x,  por lo tanto, el Teorema de Fubini se cumple perfectamente.

  La función a integrar es continua y  utilizando el límite para \( \epsilon \) ya hemos eliminado el problema en x=1 donde la función es infinita.

  En definitiva la integral existe, y su resultado es:

    \( \vec E = -2 \pi G \rho \vec i  \) donde \( \rho \) es la densidad  de masa en superficial de la esfera

    o lo que es lo mismo    \( \vec E = - \frac{GM}{2R^2} \vec i \) 

    Con todo esto ya debe estar claro todo.

    La integral existe, el teorema de Rubini se cumple  y su valor es el  que expuesto anteriormente y por lo tanto NO  se obtiene  infinito  como resultado de la integral como has dicho que has demostrado. 

   Un saludo.

[DCM]

Hola a todos. ¡Ya tenemos simulador! Con su panel de control y todo.  Lo he subido aquí para que podáis jugar con él:

https://force-field-particles-simulator.vercel.app/



Aquí está el código fuente:

https://github.com/danielthetechie/force-field-particles-simulator/tree/main/src

Los ficheros más relevantes (donde está contenida la física del programa) son Universe.js y Particle.js.

También es apta para tierrahuequistas como nuestro amigo DCM, ya que se puede configurar para que la distancia inicial de todas las partículas con respecto del origen sea igual al radio del universo (como en el gif de arriba), esto es, que no haya partículas en el interior de la esfera. El único inconveniente es que no tiene un final feliz para DCM, sino que el final es el que predijo Richard unos cuantos mensajes más atrás:

      DaniM, te doy la enhorabuena por el simulador que has conseguido, un trabajo muy bueno, así lo creo.

       Pero creo que lo que no vemos es lo que pasa dentro de la esfera final. Lo cual es lo importante.

      Como ya he dicho anteriormente inicialmente la semilla primogénita empieza  a atraer todo el material que encuentra en su trayectoria, todo lo que pilla y se va formando una esfera cada vez más grande, más grande, y esto es así mientras la masa de esta esfera no sea suficiente para que la gravedad de las capas superiores no provoquen suficiente gravedad para que las capas del interior se despeguen del núcleo.
    Cuando la masa y diámetro de la esfera es ya de un valor   mayor a la atracción de la gravedad de la semilla primogénita y su entorno, entonces empieza a  crearse la esfera hueca. 

   Inicialmente se forma una esfera maciza,  que conforme crece se hace inestable por lo que he comentado en mensajes anteriores y entonces empieza a crearse la esfera hueca.

   DaniM, lo que vemos en tu simulación son los primeros momentos del inicio del planeta, y además vemos lo que pasa en el exterior, pero no lo que pasa en el interior.

   Bueno os  muestro lo que pasa en el interior en la siguiente simulación, cuando actúa el campo gravitatorio según lo que he obtenido y he explicado en este hilo, de las esferas huecas, no tiene que ver con el nivel que tú has compartido pero va a ayudar a comprender lo que estoy explicando:
   esquema de movimiento de las partículas.


   video de la simulación.



   Como podéis ver en el interior la materia de las capas más interiores (color azul) se desplazan hacia la superficie y la materia de las capas superiores (color verde) se desplazan hacia el centro. Llegando a crearse una esfera hueca de un radio menor al inicial. La materia está siendo comprimida.  En la simulación el espesor final no es real.

   Pues así es como funciona todo Sres.  La esfera de masa maciza es inestable y su estado estable es una esfera hueca. Sólo existirán esferas macizas que  la gravedad de las capas superiores no puedan provocar este fenómeno que describo, por que esté el núcleo muy compactado y no tenga suficiente masa en las capas exteriores.

  Muchas gracias DaniM por tu aportación.

   Un saludo.

[DaniM]

lo que vemos en tu simulación son los primeros momentos del inicio del planeta, y además vemos lo que pasa en el exterior, pero no lo que pasa en el interior.

Pero DCM, se supone que la simulación está recreando el interior de una esfera de radio \( R \) con partículas dentro! Mira lo que pasa con una esfera hueca de radio \( 200 \) unidades:

video de la simulación.



Como podéis ver en el interior la materia de las capas más interiores (color verde) se desplazan hacia la superficie y la materia de las capas superiores (color azul) se desplazan hacia el centro. Llegando a crearse una esfera hueca de un radio menor al inicial. La materia está siendo comprimida.

Por curiosidad, ¿cómo has conseguido que las partículas formen una esfera hueca? ¿Has metido las fórmulas físicas (¿cuáles y dónde?) y ha ocurrido eso de forma espontánea, es decir, sin ninguna otra acción por tu parte, o cómo?