Comments (31)
I think \tau_0 in that slide is the same as \tau_0 in pyTDGL, i.e., \tau_0 = \mu_0\sigma\lambda^2. The values for \xi_0 and \lambda_0 in that slide look reasonable. I have no idea about the value of \gamma in YBCO.
Here is one estimate of the inelastic scattering rate for YBCO (inset of right plot): \tau_{in} = 10-100 ps over some range of temperatures. It seems like everyone agrees that the inelastic scattering time is strongly temperature dependent in the cuprates.
![image](https://private-user-images.githubusercontent.com/20325010/274364158-3cbbaa1b-db44-45be-b424-07a9d3eb7748.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MTk0NjAwNjAsIm5iZiI6MTcxOTQ1OTc2MCwicGF0aCI6Ii8yMDMyNTAxMC8yNzQzNjQxNTgtM2NiYmFhMWItZGI0NC00NWJlLWI0MjQtMDdhOWQzZWI3NzQ4LnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNDA2MjclMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjQwNjI3VDAzNDI0MFomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPTJkYmZmYjEzNzQ1ZjNiODk2MDU5ZGU1MmU0Mzk5OGIxODJkMThiZjc4OTk0Mjc5Mzc2OTAyOTIwNmUyYjI0MzUmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0JmFjdG9yX2lkPTAma2V5X2lkPTAmcmVwb19pZD0wIn0.zWhXYDu5GJFUMiKKGqiBTBFYj24JukJFZWZ4P85bpoM)
PDF of this paper:
1-s2.0-0921453495004114-main.pdf
from py-tdgl.
I think you should use the temperature-dependent value of all parameters, evaluated at the temperature of the experiment.
In some formulations of TDGL, you input the T=0 values of the material parameters and the ratio t=T/T_c. The functional form of the temperature dependence \xi(t), \lambda(t) is then included in the TDGL equations. However in pyTDGL, you should specify the value of the parameters that you think the material has at the temperature of the experiment.
There is the question of how close to T_c is close enough for GL theory to be valid. I don't really know the answer - people often apply GL theory even far below T_c for lack of a better model. However, I have seen papers claiming at the "GL region" is T >= 0.85 * T_c (for example, Fig. 16 of this paper https://arxiv.org/abs/2205.15000). For optimally doped YBCO at LN2 temperature you have 77 K / 93 K = 0.83, so it is pretty close.
from py-tdgl.
Screening will definitely be a very big effect in that case. Let's say london_lambda = 5 um, so the effective penetration depth is Lambda = london_lambda^2/d = (5 um)^2 / (0.2 um) = 125 um << 5,000 um, meaning screening can't be neglected. Even including screening in a simulation of a much smaller geometry will not be sufficient, since the strength of screening is dictated by Lambda / (minimum sample dimension perpendicular to the applied field). It's clear from the top left MOI image that the magnetic field is essentially completely screened from the interior of the sample before vortices penetrate.
To get the same effective strength of screening for your simulated geometry of L = Lx = Lx = 1000 nm, you could try artificially making london_lambda much smaller, such that london_lambda^2 / (d * L) = 125 / 5,000, i.e. london_lambda = 70 nm and running the simulation with screening included (I would recommend trying the GPU for this). This obviously will mean that the GL parameter kappa is much smaller than in real YBCO, but it should capture the effect of screening in a much more realistic way. The lower critical field will also be much larger with a shorter london_lambda.
By the way, here is a London simulation using SuperScreen of the sheet current density and magnetic field for B_{z, applied} = 0.1 mT:
from py-tdgl.
Okay it is now working, thank you! Not sure what happened, it could be because I did not plot the last entry in solutions with _ = solutions[-1].plot_currents()
.
from py-tdgl.
Would that then start to append the rest of the simulation to the same file?
No, you would have to specify a new options.output_file
It would be nice to have a similar mesh generation status like in pyTDGL so that if there are malformed cells we can quickly adjust the settings.
SuperScreen actually doesn't need to construct Voronoi cells at all. The numerical method that SuperScreen implements will work with practically any mesh - it is much more forgiving than pyTDGL in that way. I could add a progress bar for mesh smoothing, but to be honest, smoothing is completely optional and doesn't affect the simulation results very much in SuperScreen.
from py-tdgl.
Yes, you can calculate Mz vs. Bz, but the curve will always be a straight line with negative slope that passes through the origin because the supercurrent density scales linearly with the magnetic field
![image](https://private-user-images.githubusercontent.com/20325010/275248054-a6938384-a06c-41ab-a5c6-9a10356fade3.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MTk0NjAwNjAsIm5iZiI6MTcxOTQ1OTc2MCwicGF0aCI6Ii8yMDMyNTAxMC8yNzUyNDgwNTQtYTY5MzgzODQtYTA2Yy00MWFiLWE1YzYtOWExMDM1NmZhZGUzLnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNDA2MjclMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjQwNjI3VDAzNDI0MFomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPTc0ZWRlYmU4NDkyMWE0Y2Q2NmJhMGYxYTBkODhmZmI3YWVlYzQyNTkyY2U2ODkyOGY4MDNjZWY0NWM1NmM0OTAmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0JmFjdG9yX2lkPTAma2V5X2lkPTAmcmVwb19pZD0wIn0.YMzgwLVXi3clUVYufp3SidMkk4lVRhsm8whOKSZ-Z4s)
from py-tdgl.
Since TDGL is well defined near Tc is it best practice to use the temperature dependent parameters for coherence length and penetration depth? I have noticed that most papers just use the value near 77K even if Tc is roughly 90k.
Oh and since 81.6K resulted in a \tau_{in} = 10 ps I would expect if we extrapolate to 90K gamma should tend towards 0. It is difficult to know whether to use values near Tc or just the temperature in the real experiment.
from py-tdgl.
Anyway to get around the increase in computation time when gamma >> 10? Simulation times went from roughly 12 hours with gamma=1 to 80 hours with gamma=100. Maybe using the GPU versions of the sparse_solver might be beneficial here? I will try it soon.
from py-tdgl.
I also found a paper that has the temp dependence of YBCO superconducting energy gap if anyone was interested:
Wang, Ji & Li, Hao & Cho, Ethan & LeFebvre, Jay & Pratt, Kevin & Cybart, Shane. (2020). Portable Solid Nitrogen Cooling System for High Transition Temperature Superconductive Electronics. IEEE Transactions on Applied Superconductivity. PP. 1-1. 10.1109/TASC.2020.2986324.
So del = 2.5 meV roughly for 85K, and if we extrapolate for scattering time in the paper you sent t = 5ps roughly. This results in a gamma = 2 * t * del / hbar = 38, so an order of magnitude approximation of gamma = 10 for YBCO should suffice to improve sim time.
from py-tdgl.
Large gamma requires the solver to choose a very small time step, which is why the simulation time increases so much. I am not sure if there is a way around it - I will have to think about it. In the meantime, your rationale for using gamma = 10 makes sense to me. The very large gap of YBCO makes things difficult... Using tdgl.SolverOptions.gpu = True
should help a bit, although I don't think it will help more for large gamma than for small gamma.
from py-tdgl.
I'm not sure how it is done in the backend, but could you use an adaptive mesh proportional to the Laplacian at mesh sites? You would still have a maximum global edge length to maintain a somewhat accurate simulation before the introduction of any fluctuations to the order parameter. I am not sure how computationally expensive it would be to adjust the mesh at each time step, but perhaps the mesh generation could be done on the GPU as well? I have no idea how difficult this kind of implementation would be.
from py-tdgl.
I have been trying to simulate the nucleation of vortices similar to how it is shown in MOI by my colleagues in the above. I realised that the reason the vortices do not nucleate the same way in the simulations is because of the repulsion from the edges. Since we cannot simulate a sample size comparable to the experiment, the edges need to be considered. When the thin film is macroscopic, the edge repulsion is significantly < the repulsion between vortices. This results in nucleated vortices clustering near edges. On a microscopic scale, the edge repulsion becomes comparable to the repulsion between vortices and so we are left with the vortices dispersing throughout the sample.
nobiasPureG10.mp4
Is it possible to tune the strength of the repulsion from the boundary? This may also be a consequence of the pinning landscape.
from py-tdgl.
Unfortunately, I suspect that your experimental samples may simply be way too thick to accurately be modeled by a 2D model. Screening, the vortex-vortex interaction, and the vortex-edge interaction will all be very different in samples that are thick relative to xi and lambda.
from py-tdgl.
I am not sure how computationally expensive it would be to adjust the mesh at each time step
Changing the structure of the mesh at each time step would be extremely slow
from py-tdgl.
I was hoping that since its superconducting properties are strongly anisotropic and are dominated by the CuO planes that TDGL would work well for a 200nm thick film. I guess I can still observe the vortex dynamics throughout a pinning array without directly comparing the nucleation to MOI.
from py-tdgl.
I am not sure how computationally expensive it would be to adjust the mesh at each time step
Changing the structure of the mesh at each time step would be extremely slow
Maybe you could 'fake' the inelastic scattering effect? Potentially you could interpolate the order parameter in the wake of vortex movement like you would blur an image and the degree of blurring is related to gamma? I'm not even sure if this is a realistic approach.
This section with gamma = 10 reminded me of slime mold simulations that I did in the past.
from py-tdgl.
What are the dimensions of the MOI samples?
from py-tdgl.
5x5 mm in area, and 200nm thick. The samples were at roughly 10K to provide optimal resolution with MOI.
from py-tdgl.
I have been meaning to try SuperScreen as well! It looks really good! Thank you for the detailed explanation. Also, any reason you chose 5um for London Lambda instead of 0.150um? Was it to get a quick output from SuperScreen? And I just noticed the boundary around the 5x5mm sample, what is that? I took a look at the documentation and noticed that the mesh is generated such that it envelops everything even holes with some padding. Is this because it also calculates the inductance over vacuum?
Edit: I just noticed in the second figure the non-zero field around the film, so yes this must be the case :)
from py-tdgl.
Also, any reason you chose 5um for London Lambda instead of 0.150um?
You should apply the reasoning I described using whatever value of london_lambda you think the samples have. Here's some references: https://hoffman.physics.harvard.edu/materials/ybco/. If london_lambda in the ab plane is really 150-200 nm, then the method I described may not work. The scaled london_lambda for your simulated geometry would only be about 3 nm. Unfortunately the real sample geometry makes it very difficult to apply 2D TDGL in any realistic way.
In SuperScreen, the solve time is independent of Lambda, and xi is completely irrelevant. The simulation method is inherently self-consistent so, unlike in TDGL, there is no need to do an iterative calculation of the induced magnetic field. This makes SuperScreen fast regardless of the strength of screening.
I just noticed the boundary around the 5x5mm sample, what is that? I took a look at the documentation and noticed that the mesh is generated such that it envelops everything even holes with some padding.
In SuperScreen, the vacuum inside of holes always has to be meshed. Meshing the vacuum surrounding the film is optional (see below, where I set buffer=0
when generating the mesh). By default, a small region of vacuum around the film is meshed because one often wants to visualize the magnetic field outside the sample as well.
![image](https://private-user-images.githubusercontent.com/20325010/274962752-6a05d407-74de-4dc2-8f8c-3c77472fca2f.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MTk0NjAwNjAsIm5iZiI6MTcxOTQ1OTc2MCwicGF0aCI6Ii8yMDMyNTAxMC8yNzQ5NjI3NTItNmEwNWQ0MDctNzRkZS00ZGMyLThmOGMtM2M3NzQ3MmZjYTJmLnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNDA2MjclMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjQwNjI3VDAzNDI0MFomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPWM5ZDgxZmU0NjYzYjM0ZTgxZTQ2ZDFmMzBlNTY0NTQxMGMwMDdhOGQ1YzBhMmJhMDQ0NTE2YzY2NWE2NmIyMjgmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0JmFjdG9yX2lkPTAma2V5X2lkPTAmcmVwb19pZD0wIn0.6pnOFLoSlv50Gv0hgGCOqYjXOkSWAiR8ExgliFwzxgA)
from py-tdgl.
I started using Superscreen but noticed that the mesh generation takes an extremely long time for that 5000x5000um sample that you did. I also cannot get a similar output to you for the same parameters, this may be a result of my mesh size. Your computer seems to behave really well with the meshing stage, reaching 20000 it/s whereas mine can only handle maximum of 2000 it/s. I will try uninstalling Scipy and using conda to install like you suggested before. Sorry for posting Superscreen related issues here but I believe it is best when considering the context of the discussion.
length_units = "um"
# Material parameters
london_lambda = 5
d = 0.2
layers = [sc.Layer("base", london_lambda=london_lambda, thickness=d, z0=0)]
# Device geometry
total_width = 5000
total_length = 5000
films = [sc.Polygon("film", layer="base", points=box(total_width, total_length))]
device = sc.Device(
"pure_square",
layers=layers,
films=films,
#holes=antidots,
length_units=length_units,
)
device.make_mesh(max_edge_length=100, smooth=100)
fig, ax = device.plot_mesh(show_sites=False)
_ = device.plot_polygons(ax=ax, color="k")
applied_field = sc.sources.ConstantField(0.1)
solutions = sc.solve(
device=device,
applied_field=applied_field,
field_units="mT",
current_units="mA",
)
from py-tdgl.
Hmm, that doesn't make much sense to me. Try running this notebook on Google Colab and locally, and let me know if you still see a discrepancy: https://gist.github.com/loganbvh/cc5453195153f7b5831ea95174b4091f
from py-tdgl.
Does the meshing still take a very long time? This takes about 23 seconds on my laptop:
![image](https://private-user-images.githubusercontent.com/20325010/275143393-aa7d745d-9f77-40f2-a640-2eeba259c48a.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MTk0NjAwNjAsIm5iZiI6MTcxOTQ1OTc2MCwicGF0aCI6Ii8yMDMyNTAxMC8yNzUxNDMzOTMtYWE3ZDc0NWQtOWY3Ny00MGYyLWE2NDAtMmVlYmEyNTljNDhhLnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNDA2MjclMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjQwNjI3VDAzNDI0MFomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPTQzYmZlZGYwMDJmYzhkOTc0YjVlN2JiODg3MmUzZmQ5OTBlOTZlMGMyMmU1ZWE4ZDRiYmUyMmUyZmFhMjA1NTMmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0JmFjdG9yX2lkPTAma2V5X2lkPTAmcmVwb19pZD0wIn0.Fh1p4TZ7pApxKU5gtZTsDc4bVLzIul83EIGwMFG9TAw)
from py-tdgl.
My PC just crashed halfway through a 2 day simulation :( Do you think I can just load the h5 file and resume it? I will test how long mesh generation takes in a bit.
from py-tdgl.
The mesh took me 15 seconds roughly to generate. In your first post with Superscreen above the rounded corners of the vacuum region looked like higher mesh density so I assumed you had used a smaller max_edge_length
. It would be nice to have a similar mesh generation status like in pyTDGL so that if there are malformed cells we can quickly adjust the settings.
from py-tdgl.
Do you think I can just load the h5 file and resume it?
You may be able to load the TDGLData
from the H5 file and use it as the seed solution for a new simulation. I have not tried this, but I think it should work.
import h5py
from tdgl.solution.data import TDGLData, get_data_range
with h5py.File(<h5-path>, "r") as h5file:
first, last = get_data_range(h5file)
class DummySolution:
pass
tdgl_data = TDGLData.from_hdf5(<h5-path>, last)
seed_solution = DummySolution()
seed_solution.tdgl_data = tdgl_data
solution = tdgl.solve(device, ..., seed_solution=seed_solution)
from py-tdgl.
Would that then start to append the rest of the simulation to the same file?
from py-tdgl.
The file cannot be loaded due to: Unable to open file (bad object header version number)
. I tried also visualizing it but it results in the same error. Perhaps it needs some data to tell it the file ends here and then it can be loaded?
from py-tdgl.
In Superscreen, to get the magnetization of the film can we do the same method using the sheet current?
The stream function provides the local magnetization but can we have an output of the total as well to create a magnetic hysteresis plot (Bz vs Mz)?
from py-tdgl.
from py-tdgl.
I am not too familiar with these models, but I feel intuitively that you could obtain obtain a curve by keeping the scale of sheet current the same and adjusting field like this:
Then taking the average pixel intensity over the entire film to determine a magnetization value at each field. What do you think? Technically, since we have the K data no need to do pixel intensity. I have not read too much on simulation techniques for superconductors but with the MOI data you could effectively determine magnetization via this method so I thought the same could be applied here.
from py-tdgl.
Related Issues (20)
- Error: Unable to create group during Solve HOT 14
- ParaView Visualization HOT 2
- make_mesh for Large Geometries HOT 10
- Modify Axis Limits in Visualize HOT 9
- Using Adaptive Library to Simulate a Range of Field Oscillations HOT 1
- Time dependent disorder_epsilon HOT 4
- Post Simulation Probe Points HOT 2
- Real-time monitor hangs for large geometries HOT 9
- High Fluxoid Error with No Screening HOT 6
- tdgl.visualize --output not recognized HOT 2
- Pixel Current Artefact HOT 8
- errors during tdgl testing HOT 40
- Field cooling in TDGL? HOT 1
- TypeError with Pardiso solver HOT 5
- Device with different layers/materials HOT 2
- Does not work with pint version 0.24 HOT 3
- Append new solution to seed solution HOT 1
- Add vector potential from magnetization distribution
- Traceback on quickstart.ipynb HOT 7
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
π Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. πππ
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google β€οΈ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from py-tdgl.