Lo del núcleo de alta densidad no lo entiendo....
Si la gravedad depende de las masas, el núcleo "tiraría" de la corteza hasta hacer una esfera maciza....

No sé, igual en una de estas nos descubre que el núcleo es un agujero negro y que estamos orbitando a su alrededor xD

Estaba preguntándome cómo encaja DCM su modelo de Tierra hueca con temas como las erupciones volcánicas (¿irá el magma viajando a través del vacío de un punto a otro de la Tierra?), cómo explica la existencia del campo magnético terrestre, o si los sismógrafos que miden las diferentes velocidades a las que viajan las ondas sísmicas a través de las diferentes capas de la Tierra son un timo (porque la Tierra es hueca, no hay capas).

De repente, la mitad de toda la ciencia que conocemos está mal. 🤯

Otra cuestión: si DCM da por válidos la masa y el radio de la Tierra que conocemos (unos \( 6\cdot{}10^{24}\textrm{kg} \) y \( 6370\textrm{km} \), respectivamente), no debería ser la densidad superficial de la Tierra hueca extremadamente grande? Vamos, que conseguir levantar una piedra del suelo tendría mérito...

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?

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.

Hola Richard,

Una simulación clarificadora

Podría presentarlo programado pero no trabajo gratis para nadie que no lo apreciará jaja

  para programar

Definimos
el espacio de trabajo variable $$R$$ digamos 1000 unidades
el número de partículas $$n$$ unas 100 para que no sean pocas ni muchas
el tiempo entre evaluación y evaluación el sistema, muy corto evoluciona lento, muy largo es impreciso supongamos $$t=1$$
definimos el valor $$G$$ que puede ser el de la constante de gravitación, pero como todo es proporcional a este número  los resultados no difieren si se lo escoge unitario $$G=1$$ valores mas chicos hacen mas lenta la evolución
la densidad volumétrica de las masas $$\rho$$ , es anecdótica sirve para definir un radio de cada partícula
definimos una matriz o arreglo con $$n$$ filas y 11 columnas(masa $$mi$$ ,$$ri$$ radio propio,$$x,y,z,vx,vy,vz,fx,fy,fz$$   )
con un bucle hasta $$n$$, asignamos aleatoriamente

asignamos aleatoriamente $$mi$$, masa de la partícula
con esto definimos su radio $$ri =\sqrt[3]{\dfrac{mi}{rho \frac43 \pi}}$$
asignamos aleatoriamente $$0<r<R$$ distancia respecto del centro
asignamos aleatoriamente $$0<\theta<2\pi$$ ángulo respecto del centro
asignamos aleatoriamente $$0<\varphi<\pi$$ ángulo azimutal respecto del centro

con $$r , \theta$$ y $$\varphi$$  traducimos coordenadas esféricas a cartesianas asegurando  que todas las partículas estén dentro de una esfera de radio $$R$$

$$xi = r\sen\,\theta\,\cos\varphi$$
$$yi = r\sen\,\theta\sen\,\varphi$$
$$zi = r \,\cos\theta$$

suponemos que la velocidad inicial de las partículas es nula
$$vxi=0$$
$$vyi=0$$
$$vzi=0$$

hacemos el inicio de un contador de tiempo $$T$$ iniciando en cero

Iniciamos un bucle hasta que el tiempo $$T$$ sea el deseado $$T>1000000$$ por ejemplo

luego para cada partícula de 1 a $$n$$ llamada con subíndice $$i$$ hacemos un bucle
se ponen a cero cada componente del vector fuerza que siente cada partícula $$i$$

$$fxi=0$$
$$fyi=0$$
$$fzi=0$$

y otro bucle de 1 a  $$n$$ con subíndice $$j$$

si $$i=j$$ no hacemos nada
calculamos la distancia entre partículas

$$dij=\sqrt{(xi-xj)^2+(yi-yj)^2+(zi-zj)^2}$$

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

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

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

esto tratará las dos partículas como si fueran una sola y ya no calculara mas su interacción sin alterar el número de partículas del programa

y evitará divisiones por cero

si la $$dij$$ es mayor entonces

calculamos cada contribución de fuerza de cada partícula  de 1 a $$n$$ como

$$fxi=fxi+G\cdot mi\cdot mj (xj-xi)/dij^3$$
$$fyi=fyi+G\cdot mi\cdot mj (yj-yi)/dij^3$$
$$fzi=fzi+G\cdot mi\cdot mj (zj-zi)/dij^3$$

al final del ciclo j  tendremos la fuerza que siente la partícula i
asignamos esos valores a la matriz de datos

reiteramos para todas la partículas i terminando el ciclo i

luego trabajamos sobre la cinematica

en un nuevo ciclo i

calculamos la aceleracion como

$$axi=fxi/mi$$
$$ayi=fyi/mi$$
$$azi=fzi/mi$$

la nueva velocidad en ese instante
$$vxi=vxi+axi\cdot t$$
$$vyi=vyi+ayi\cdot t$$
$$vzi=vzi+azi\cdot t$$

y la nueva posición en ese instante

$$xi=xi+vxi\cdot t+\dfrac12 axi \cdot t^2$$
$$yi=yi+vyi\cdot t+\dfrac12 ayi \cdot t^2$$
$$zi=zi+zxi\cdot t+\dfrac12 azi \cdot t^2$$

cerrar el ciclo

luego un proceso para representar en pantalla , cada partícula con su radio, y transformar la posición 3d calculada en 2d de pantalla

hacemos que sume tiempo el contador
$$T=T+t$$
y cerramos el ciclo del contador $$T$$ así todo se vuelve a recalcular cada un tiempo $$t$$


Que surge de esto ....

• En pantalla debe observarse la disminución de la cantidad de partículas cada vez que chocan.
• Que cada vez que se acercan mas al centro mas velocidad adquieren,
• Que siempre habrá una dirección en el espacio donde se formar un plano o disco de acreción,
• 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, así DCM modela su formación de tierra hueca , y si en modelos no funciona en la naturalez tampoco.
• En realidad no hace falta modelizar los choques inelásticos, pero si no se hace, se verá que de alguna manera el sistema tiene que liberarse de energía cinetica  debido a la conservación de la energía y se lo podrá observar  expulsando algunas masas fuera del sistema, si tienen mas velocidad que la de escape , nunca regresan, sino pueden permanecer en órbitas largas como los asteroides, o la nube de oort ... pero bueno hay que meter muchas partículas de variada masa para ver efectos notables, y un pc muy rápido...

[cerrar]

Resulta que me he puesto a programarlo.  Pero me ha surgido una duda. Aquí:

con esto definimos su radio $$ri =\sqrt[3]{\dfrac{mi}{\rho \frac43 \pi}}$$

¿Habría algún inconveniente en asignar el radio de la partícula directamente, sin definir previamente \( \rho_i \) para luego hacer ese cálculo? ¿Y alrededor de qué valores mínimos y máximos de \( \rho_i \) y \( m_i \) nos moveríamos para poder hacer la simulación más interesante? Lo pregunto porque si aparecen partículas 1000 veces más masivas que otras, igual la historia termina pronto...

DaniM, menos ningunear a las personas y más argumentos matemáticos o físicos o lógicos.

Para qué, si ya te han dado todos los argumentos habidos y por haber y aun así no te has molestado en comprenderlos. Yo pensaba que, como dijo Richard, te has radicalizado en una idea absurda y de ahí ya no sales, pero desde que has empezado con lo de la Tierra hueca, los astros huecos, supongo que también las estrellas estarán huecas y todo hueco... pienso que hay una probabilidad no nula de que seas un troll, de que en el fondo no te creas nada de lo que tú mismo dices y que estés en tu casa descojonándote de las reacciones en el foro cuando posteas tus disparates y esperas una semana entera para volver con la caja de palomitas. Confiésalo ya, tú en la intimidad tampoco divides por cero, ¿verdad?

Quizá con una animación se entendería mejor, porque no entiendo bien ¿por qué si un trozo de materia atrae otros quedaría hueco con trozos dentro? Pero en 3d está difícil.

El problema es que para hacer una animación tienes que introducir las fórmulas matemáticas de antemano, no es que tú crees un mundo virtual desde cero y "que la naturaleza siga su curso", sino que para hacer dicha animación con partículas habría que definir primero qué trayectorias seguirían éstas en base a la ecuación de la gravedad, y el aquí el tema es que la ecuación de DCM está mal, como ya ha quedado explicado en las páginas anteriores, por lo que cualquier parecido que tuviera la animación con la realidad sería pura coincidencia.

No sé cómo lo ha hecho él, pero Wolfram Mathematica te permite hacerlo con cualquier tipo de contorno si no recuerdo mal, utilizando series de Fourier con un determinado número de sumandos. A más sumandos, más precisión. En el siguiente enlace lo explican en más detalle:

https://mathematica.stackexchange.com/questions/171755/how-can-i-draw-a-homer-with-epicycloids

Entonces, lo que haría yo, diseñaría una curva en algún programa como inkscape o similar, y luego le aplicaría lo comentado en el enlace anterior. Además hoy en día con lenguajes de programación como Julia seguro se puede implementar lo mismo que con Wolfram Mathematica de manera mucho más eficiente, en principio utilizando wavelets en vez de senos y cosenos, ya que son más indicados en general para trabajo digital.

¡Muy bueno! Hasta ahora había visto los típicos cardioides y otras formas simples, pero no me imaginaba que se pudiera parametrizar una curva hasta el punto de crear algo tan sofisticado como un Bart Simpson. 

Por curiosidad, ¿es imprescendible usar números complejos para ello o es simplemente más cómodo o rápido? Veo que en el enlace que has puesto dice:

the idea is to transform each point as a complex number (z) and take the Discrete Fourier Transform (cn) up to a prescribed order m

Y en la ecuación de la botella de agua veo que también aparecen números imaginarios. ¿Sería posible conseguir un resultado similar trabajando únicamente con números reales, dado un conjunto de puntos? Estoy pensando en juntar varias ecuaciones del estilo \( r = f(\theta) \) definidas en sistemas de coordenadas polares; no sé qué tan viable sería eso.

(...) los políticos son solo "correveidiles" (como diría Cantinflas), es decir, marionetas y herramientas de otros individuos "poderosos" que, en la sombra, son quienes, en realidad, se meten en la vida de la gente y la manipulan, adoctrinan y condicionan mediante auténtica ingeniería social.

¿Estás pensando en los Illuminati o en particulares con nombres y apellidos (¿quiénes?)?

En cualquier caso no creo que el illuminati de turno que le haya dado su lista de mandados a Pedro Sánchez esté a salvo de sus mentiras. 

Otra cosa más, pones b = [lista[-1]] + inversa(lista[:-1]), donde “inversa” es la función que se está ejecutando, y todavía en ese punto no has terminado de definir dicha función.

Es cierto que podría haber hecho simplemente

return lista[-1] + inversa(lista[:-1])
y ahorrarse las dos siguientes líneas, pero de la otra manera también funciona porque a la hora de ejecutar el programa, lo que hace el intérprete por dentro es evaluar la cadena de llamadas a la función hacia atrás, es decir, primero hace inversa("") y devuelve "", luego vuelve a inversa("a"), asigna b = "a" + "", hace el join (que como dices, es innecesario) y devuelve "a", luego vuelve a inversa("ra"), asigna b = "r" + "a", hace el join y devuelve... y así hasta que llega a inversa("palabra"), es decir, que aunque ella llame la función dentro de sí misma antes de hacer el return final, a la hora de la ejecución lo que va después se sigue evaluando en cada llamada.