SPLASH is an interactive visualisation and plotting tool using kernel interpolation, mainly used for Smoothed Particle Hydrodynamics simulations
Home Page: https://splash-viz.readthedocs.io
License: GNU General Public License v2.0
I wonder whether it might be possible to render column densities of particle types 2, 3 and 4 from files in Gadget-2 format. They represent star particles in my simulations and it would be particularly helpful to overplot their surface density contours on top of rendered figures showing gas (parttype=0) properties.
can do this in separate panels, current workaround is to create a bunch of ascii files that have to be read in separately
Hi,when I tried to run splash using:
splash grtde_000164
to visualize something,then errors appeared which would be like:
dyld[45594]: Library not loaded: /opt/homebrew/opt/hdf5/lib/libhdf5.200.dylib
Referenced from: <B30C583A-9A42-342D-8E2A-2A3B16F5456F> /opt/homebrew/Cellar/splash/3.5.1/bin/splash
Reason: tried: '/opt/homebrew/opt/hdf5/lib/libhdf5.200.dylib' (no such file), '/System/Volumes/Preboot/Cryptexes/OS/opt/homebrew/opt/hdf5/lib/libhdf5.200.dylib' (no such file), '/opt/homebrew/opt/hdf5/lib/libhdf5.200.dylib' (no such file), '/usr/local/lib/libhdf5.200.dylib' (no such file), '/usr/lib/libhdf5.200.dylib' (no such file, not in dyld cache), '/opt/homebrew/Cellar/hdf5/1.14.2/lib/libhdf5.200.dylib' (no such file), '/System/Volumes/Preboot/Cryptexes/OS/opt/homebrew/Cellar/hdf5/1.14.2/lib/libhdf5.200.dylib' (no such file), '/opt/homebrew/Cellar/hdf5/1.14.2/lib/libhdf5.200.dylib' (no such file), '/usr/local/lib/libhdf5.200.dylib' (no such file), '/usr/lib/libhdf5.200.dylib' (no such file, not in dyld cache)
zsh: abort splash
I don't kown how did it happen...and I've tried several ways like reinstalling hdf5 package but it does not work.
Dear professor Daniel Price
The bug of splash is about the command "splash calc tracks" command. It doesn't work on StarSmasher but neither in Swiftsim...
The others splash calc commands works very well and they produce the file that they promise to produce. However the splash calc tracks doesn't work, here is what happens (with Starsmasher, i also tried it in swiftsim and it doesn't work also there)
First i use /xw and i press "t" to select the particles, then
q
l
I can see the particle that is been saved, i set then the particle limits
set
set
set
set
0
and then i press S to produce tha splash.limits file
Then i press q and i write:
jsplash (i did this alias for the StarSmasher command) calc tracks out*.sph
And it starts to write so:
read splash.defaults
501 filenames read from command line
----------------------- out0000.sph -----------------------
time : 1.1040916432267327E-002
N_total : 139896
N data columns : 13
last step ntot = 139896
read splash.units
read splash.limits
-----> CALCULATING tracks vs time for all dump files
-----> CALCULATING TRACKS, TIME= 2.04E-04 FILE # 1
And so on for the others 500 snaps. At the end it writes:
----------------------- out0499.sph -----------------------
time : 49.906836273424069
N_total : 139896
N data columns : 13
last step ntot = 139896
-----> CALCULATING TRACKS, TIME= 9.21E-01 FILE # 500
----------------------- out0500.sph -----------------------
time : 50.002533158971630
N_total : 139896
N data columns : 13
last step ntot = 139896
-----> CALCULATING TRACKS, TIME= 9.22E-01 FILE # 501
-----> FINISHED CALCULATING TRACKS (USED 501 DUMP FILES)
But no file tracks-123.out is been created! I hoped that this command could sign the x y z cordiantes of the particles vs time and produce a picture that is pretty similar to the figure 10 of this paper:
https://iopscience.iop.org/article/10.1088/0004-637X/786/1/39/pdf
I sent an email some weeks ago, but without answer. Here there are some StarSmasher snapshots.
Best regards
Francesco
Dear Professor Daniel Price
On Swiftsim simulations, it's impossible to color a set of particles and follow them, as you can see from these 2 snapshots, advancing in the simulation will result in a kind of color bug
I also attach some snapshots of the simulation in a zip file. I hope you can solve...
Best Regards and Thank you!
Francesco
snapsfordaniel.zip
Currently, the double rendering option sets the top layer to become transparent in regions where the rendered quantity falls outside the colour bar, which is a hard cutoff. It would be nice to implement double rendering such that the top layer follows a "transparency/alpha bar" where the transparency scales with the rendered quantity.
An example use case is to indicate the hydrogen partial ionisation region on top of density as follows: Render density on the bottom layer (not necessarily with a grayscale colorbar), and render hydrogen ionisation fraction (between 0 and 1) on the top layer in some other colour, but with that colour fading away towards 0 and 1 so that the regions with ionisation fraction near 0.5 are most opaque.
When annotations (created using the g5 option) are placed outside of the box by, e.g., suppling a negative starting x position, the dimensions of the exported image does not expand to include them. Currently, a workaround is to set the page margins manually using the SPLASH_MARGIN_XMIN environment variable or --xmin flag to use a suitable negative value.
The code is working much better now, but there is a little thing not working properly: if I choose to set the marker for the 2 sink particles as a full circle proportional to h (options >32), the wrong particles are identified as the sink particles, like in this example here (the 2 green dots). It works fine when I choose markers >32.
Hello,
Nature of the problem
I'm having problems with the ssplash to grid functionality in SPLASH 2.9.1. When I specify SPLASH_TO_GRID_NPIX the output grid files contain arrays of the requested dimensions but are filled with zeros.
Goal and problem workflow
Using the attached ssplash 2.9.1 options file (cartesian.units, cartesian.limits, cartesian.defaults) and the Phantom dump file “dump” export to a cartesian grid for the specified variables:
setenv SPLASH_TO_GRID 6,10,11,12,13,16
ssplash -p cartesian.dump
In this case ssplash does produce non-empty gridded output files, but as I did not specify the NPIX resolution ssplash chooses 503x503x503.
However, if I explicitly set SPLASH_TO_GRID_NPIX and run ssplash to grid I get an error and empty grid (i.e. the entries are all zero) files:
setenv SPLASH_TO_GRID 6,10,11,12,13,16
setenv SPLASH_TO_GRID_NPIX 64,128,73
ssplash -p cartesian.dump
Excerpt from SSPLASH log file (errors marked in italics)
using NON-PERIODIC boundaries
(set SPLASH_TO_GRID_PERIODIC=yes for periodic
or SPLASH_TO_GRID_PERIODIC=yes,no,yes for mixed)
Using npixels = 64 128 73 from SPLASH_TO_GRID_NPIX
[doing velocity field components separately (low memory mode)]
allocating memory for 64 x 128 x 73 grid ... OK
-----> WRITING TO ASCII OUTPUT FILES
interpolating density to 3D grid...
density [g/cm\u3\d] min max mean
on parts: 2.05E-19 2.00E-12 3.97E-14
interpolating from particles to 3D grid (non-normalised) ...
interpolate3D: error: pixel width <= 0
density [g/cm\u3\d] min max mean
on grid : 0.00E+00 0.00E+00 0.00E+00
Note the error: “interpolate3D: error: pixel width <= 0”
Data necessary to reproduce this error
I've attached the splash options files (cartesian.units, cartesian.limits, cartesian.defaults), the Phantom dump file used is available on the thumb drive I've given Daniel Price.using NON-PERIODIC boundaries
(set SPLASH_TO_GRID_PERIODIC=yes for periodic
or SPLASH_TO_GRID_PERIODIC=yes,no,yes for mixed)
Using npixels = 64 128 73 from SPLASH_TO_GRID_NPIX
[doing velocity field components separately (low memory mode)]
allocating memory for 64 x 128 x 73 grid ... OK
-----> WRITING TO ASCII OUTPUT FILES
interpolating density to 3D grid...
density [g/cm\u3\d] min max mean
on parts: 2.05E-19 2.00E-12 3.97E-14
interpolating from particles to 3D grid (non-normalised) ...
interpolate3D: error: pixel width <= 0
density [g/cm\u3\d] min max mean
on grid : 0.00E+00 0.00E+00 0.00E+00
Note the error: “interpolate3D: error: pixel width <= 0”
Phantom simulation used + Software versions
I'm using splash 2.9.1 on Ozstar at Swinburne and on my MacMini running OSX Mojave (downloaded using Macports). Both produce the same error. The dump Phantom dump file being used comes from running Price and Bates collapsing proto-stellar core "Jet" simulation at the 137 timestep (~27,000 yrs)
Zipped splash option files
[cartesian.defaults.gz]
(https://github.com/danieljprice/splash/files/3929743/cartesian.defaults.gz)
cartesian.limits.gz
cartesian.units.gz
filed by Amanda Rubio via email:
I have a question about using splash for Mathew Bate's old code. I can get splash to read my input files correctly using "GFORTRAN_CONVERT_UNIT='big_endian' bsplash FILE*". The density rendered plots look okay, but when I tell it to go to the next time step (pressing spacebar) it is just the same image over and over again. It only changes when it loads the next dump file. So when I try to make a movie of the disk's evolution, it's super bumpy.
I have a code that reads the binary files and turns them into regular txt files: using splash to read those gives me what I expected, each new timestep read produces a new image. However, I'm not sure splash is reading that file correctly, because the densities (that are of the order of 1e-14 in the txt file) are giving a column density on the render of ~1e22. I attached an example file here. The density is in g/cm3 and xyz are in stellar radii (changing them to cm did not change my results).
splash seems to think that these are one fluid files, and makes a mess by creating fake dust particles on top of the "real" dust particles:
> reallocating memory: parts = 4175313 steps = 1 cols = 13
Creating 1975310 fake dust particles (set SPLASH_BARYCENTRIC=yes to plot barycentric values)
WARNING: deltav not found in one fluid dust data: cannot get vels
ERROR in data read: got 200000 dust particles from iamtype, but npartoftype = 196554
ERROR in data read: got 24690 unknown/dead particles from iamtype, but npartoftype = 28136
After a recent update, the menu option o1 (where you choose to plot / not plot the various particles types) only lists the particle types that exist in the current dump file. The option of plotting sink particles should always be present for the cases where a simulation is initialised without sinks, but they are created later on.
When calculating the additional quantities "dustfrac" or "dust-to-gas" with more than 7 dust phases, the string length (80) is not long enough to parse the function. Unfortunately this does not throw an error, which makes it appear as though there is an error in the data file when there is not.
A quick fix would be to use a longer string length, but perhaps a better solution would be to add the ability to parse the string "sum(dustfrac)" as "dustfrac1+dustfrac2+..."
This would also help with working with deltav, e.g. when calculating differential velocities between dust phases.
a bunch of quantities are not recognised in multigrain dust outputs from phantom... e.g. tstop just has numbers and deltav columns are just repeated a lot. Would be good to give these correct unit scalings and more useful labels.
When double rendering, the background layer is hard-coded to be greyscale. But when hard-coded to have a different colormap (just by changing the line icolours_temp = 1 inside if (gotcontours .and. double_rendering), the transparency no longer works.
Related to this issue, it would be nice to have a prompt for the colourmap of the first layer in the double rendering menu, and automatically display the colourbar (maybe half-half on the right when in Hollywood mode).
A new star formation implementation in Phantom ( see PR 577) add an array of integers to the ptmass block in fulldumps. To properly read this block, it's necessary to skip integer arrays as it is done for the gas block.
would be nice to read and store tagged items from the headers of binary file formats, i.e. any floating point number. Could then use these as the list of possible variables when calculating extra quantities, doing post-processing or plotting exact solutions.
At commit b2c7963 it seems the separation of giza from splash has caused the standard build / install process to break, After this commit when I do:
git clone https://github.com/danieljprice/splash.git
cd splash; git clone https://github.com/danieljprice/giza.git
make SYSTEM=gfortran withgiza
the build errors out with:
gfortran -O3 -frecord-marker=4 -fopenmp -I../giza/include/ -c giza-fortran.F90 -o giza-fortran.o
gfortran: error: giza-fortran.F90: No such file or directory
gfortran: fatal error: no input files
If I reset to the previous commit:
git reset --hard a5ddb7f
all is good (assuming I leave the "withgiza" option out of the make).
either by using their age and mass to give a luminosity and colour (as in real stars)
or just to give them a twinkling effect (just for show)
idea is to eliminate all compile-time variants of splash (ssplash, gsplash, etc) and compile just ONE binary called `splash'. Then the format should be either detected automatically (where possible) or given using a flag, e.g.
instead of ssplash:
splash -phantom disc_00000
instead of gsplash:
splash -gadget snap_0000
these could be made backwards compatible with simple aliases:
alias ssplash='splash -phantom'
for phantom simulations with multiple dust species, splash currently shows something like the following in the menu:
1) x [au] 43) deltavz
2) y [au] 44) deltavx
3) z [au] 45) deltavy
4) particle mass [M_{Su 46) deltavz
5) h [au] 47) deltavx
6) density [g/cm^3] 48) deltavy
7) dustfrac1 49) deltavz
8) dustfrac2 50) deltavx
9) dustfrac3 51) deltavy
10) dustfrac4 52) deltavz
11) dustfrac5 53) deltavx
12) dustfrac6 54) deltavy
13) dustfrac7 55) deltavz
14) dustfrac8 56) deltavx
15) dustfrac9 57) deltavy
16) dustfrac10 58) deltavz
17) dustfrac11 59) deltavx [km/s]
18) tstop1 60) deltavy [km/s]
19) tstop2 61) deltavz [km/s]
20) tstop3 62) v_x [km/s]
21) tstop4 63) v_y [km/s]
22) tstop5 64) v_z [km/s]
23) tstop6 65) div v [1/s]
24) tstop7 66) dt [s]
25) tstop8 67) r
26) tstop9 68) dustfrac
27) tstop10 69) log \rho_{g} [g/cm^3
28) tstop11 70) \rho_{d} [g/cm^3]
29) deltavx 71) \rho_{d,1.37\gmm} [g
30) deltavy 72) \rho_{d,2.57\gmm} [g
31) deltavz 73) \rho_{d,4.81\gmm} [g
32) deltavx 74) \rho_{d,9.01\gmm} [g
33) deltavy 75) \rho_{d,16.9\gmm} [g
34) deltavz 76) \rho_{d,31.6\gmm} [g
35) deltavx 77) \rho_{d,59.3\gmm} [g
36) deltavy 78) \rho_{d,111\gmm} [g/
37) deltavz 79) \rho_{d,208\gmm} [g/
38) deltavx 80) \rho_{d,390\gmm} [g/
39) deltavy 81) \rho_{d,731\gmm} [g/
40) deltavz 82) dust-to-gas ratio
41) deltavx 83) |v|
42) deltavy
the problem is that one cannot visualise rho_gas across full/small dumps because they appear in different columns.
Suggested changes here are to:
In this example, the 'psi' field is scalar (confirmed by opening the file with paraview). However when opened with splash, 3 fields appear ('psi_x', 'psi_y', 'psi_z'), all set to 0.
dump_0000.vtk.zip
with multigrain dust output, we need to be able to define particle "sub-types" as child types of a single generic type. Otherwise we end up with potentially hundreds of particle types which make splash unusable.
The idea is to create a single "family", so e.g. type 2 particles are still "dust", but within the dust type there are a bunch of subtypes. Of course this is just a fancy way of accessing particle types 7->n, but means high level operations (like turning all dust on/off) can be done easily.
Could also apply to star particles, e.g. bulge/disc/halo could all be subsets of the "star" particle type.
Implementing this is a bit tricky, but urgently needed
caused by pull-request #36, splash no longer compiles in single precision if HDF5=yes
I would like to place some text on each plot, either as part of the time legend or somewhere else, giving the number of sinks in that snapshot. In the legend menu it says "You can print any header variables using %(var):", but I can't find what the names of the available variables are (I'm using Gandalf for my simulations so using the Seren data reading scripts). I've tried n_sink, stot, nsink, npartoftype(3) and other variable names I have seen for this value in the code but it just puts "%variableName" on the plots.
Could you add an option to print a list of available variables that it has read from the header or put this somewhere in the documentation?
Dear professor Daniel Price
I attach you some binaries produced by the SPH code Gandalf
I tired to open them with:
splash -f seren FREEFALL1.su.* . However it gives only this errors:
plash.defaults not found: using default settings
22 filenames read from command line
----------------------- FREEFALL1.su.00001 -----------------------
*** ERROR OPENING FREEFALL1.su.00001 AS ASCII - WRONG FILE FORMAT ***
No data: You may choose from the options below
That's very strange. I've no idea why this problem happens honestly...
FREEFALL1.su.zip
Let me know..
Francesco
This would be a useful enhancement for tracking individual particles.
Issue raised by Geoff Bryan:
something is wrong with 3D interpolation to cylindrical grid, particles do not seem to interpolate correctly near -ve z boundary. Problem always occurs near -ve z boundary no matter where it is placed. Can be seen in attached png file which shows single slice (constant phi) from 3D r-phi-z interpolation (64 x 64 x 64)
would be nice if this happened automatically
Hi!
Thank you for your work on this project. I tried to pack it for Guix upstream into Astronomical package set but I've got an issue to pass tests.
~$ guix describe
Generation 340 Sep 19 2022 16:52:15 (current)
guix 72fe3c0
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: 72fe3c0a35f04a6616c17228953a20861ce9b690
~$ guix clone https://git.sr.ht/~hellseher/ffab
~$ cd ffab
~$ git checkout wip-astronomy
~$ guix build -L . splashReproduce with Make file targets
~$ make test
# or
~$ cd build; make testError:
make: *** No rule to make target 'test_interpolate3D.o', needed by 'test1'. Stop.
Regards.
Nature of the issue
I'm using ssplash to interpolate a Phantom dump file onto a cylindrical grid. The Phantom dump file is the 137 time-step (~27,000 yrs) of a Phantom "Jet" simulation of the collapse of protostar to the first core. The flow is almost axis-symmetric (but not quite :) )
When I use ssplash 2.9.1 to interpolate onto a cylindrical grid, t_he density and velocity fields are deformed near the \phi = -\pi boundary_ (I use \theta instead of \phi in the attached plots). The density and velocity fields at \phi = +\pi should be identical to those at the -\pi boundary but this is not the case.
Plots of constant density along meridional planes
Fig. 1. Contours of constant density at the $\phi = -\pi$ boundary - the contours are "deformed"
Fig. 2 Contours of constant density at $\phi = +\pi$. Note this should be identical to Fig. 1 but is quite different.
Fig. 3 Contours of constant density at $\phi = 0$ Because the flow and density are almost axisymmetric the contours for
Plot from dump to a Cartesian grid
The plot below is generated by using ssplash to dump to a Cartesian grid and plotting the density along the y = 0.0 au plane. This should be identical to plotting the
Fig. 4 Plots of constant density on the y = 0 au plane from a Cartesian grid generated by ssplash 2.9.1
Notes on the above
The plots generated from the cylindrical grid were generated on a cylindrical grid that is twice as large in its negative vertical extent as it positive vertical extent. These grids are then truncated in their negative vertical extent. This is done to reduce the effect of another ssplash issue - the fact that the interpolation produces errors at the -z boundary of the grid (See a previous issue listed in this Wiki).
There are also issues with the vector fields produced by interpolation of Phantom data onto cylindrical grids. You can check this using the codes supplied by me to Daniel Price.
Reproducing this issue
I have given Daniel Craig a thumbdrive with an archive of the data and codes necessary to reproduce this error I attach below the README.TXT file from this archive:
rendering in cylindrical coords does not seem to work properly
for multigrain dust there are a lot of column generated in the output, not all of them useful. Would be good to hide a bunch of columns by default in the menu to avoid clutter, e.g. skip from column 15 to 50 ...
sink particles in phantom snapshots produced with MPI are still not being read in correctly under some circumstances. This was partially fixed in v3.3.4 but remains an ongoing issue.
dear professor @danieljprice and developers
I kindly ask for support so that splash can read the data of the simulator "OpenSPH", one of the few simulators, along with swftsim, to be able to perform simulations of planetary and asteroidal collisions.
I attach two snapshots, one . sdf and one .ssf.
The sdf files (data files, used only for rendering) are less substantial than the ssf (state files, used for resume simulation).
I hope for your kind feedback and support
Francesco
need to know the pixel scale in the output files, this is included in the ascii output format but needs to be readable from the binary format also
Wrong repo, apologies...
Would be nice if particle tracking could automatically find the particle with maximum or minimum of a particular column (e.g. maximum density)
this is needed, some work sitting in pull request
Make a new version of the growth2multi moddump to be able to use moments to describe the grain size distribution.
At the moment it seems like splash will read splash.columns before it computes any additional calculated quantities, leading to the following warning
WARNING: array limits reached reading splash.columns, max = 14
read splash.units
Current list of calculated quantities:
15) r = sqrt((x-x0)**2 + (y-y0)**2 + (z-z0)**2) [OK]
An easy fix to this might be to just change the order of these so that splash.columns is read after the additional quantities are calculated, but I am not sure if this would interfere with anything else in splash.
When trying to manually compile giza on M1
ld: library not found for -lgiza
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [libcpgplot.la] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2
When trying to brew install Spash
#include <ft2build.h>
^~~~~~~~~~~~
1 error generated.
make[1]: *** [libgiza_la-giza-set-font.lo] Error 1
make: *** [install-recursive] Error 1
upon giving an unknown file as an argument, splash seg faults from trying to allocate memory for np=0 instead of gracefully exiting or giving the menu with "no data"
Hi,
after installing giza commit 72d3703 in /usr/local, I attempted to compile splash commit 7cd8892 from source. However,
make SYSTEM=gfortran
throws the following errors when linking:
/usr/bin/ld: giza-fortran.o: in function '__giza_MOD_giza_intern_tick_f2c':
giza-fortran.F90:(.text+0x3fed): undefined reference to 'giza_tick'
/usr/bin/ld: giza-fortran.o: in function '__giza_MOD_giza_intern_axis_f2c':
giza-fortran.F90:(.text+0x4194): undefined reference to 'giza_axis'
The linker runs with option -L/usr/local/lib -lgiza, which is the correct path:
ls /usr/local/lib/libgiza*
/usr/local/lib/libgiza.a /usr/local/lib/libgiza.la /usr/local/lib/libgiza.so /usr/local/lib/libgiza.so.0 /usr/local/lib/libgiza.so.0.1.1
Any suggestions how to fix this?
Thanks,
Wolfram
Hi Daniel,
I'm trying to make column density PDFs of a bunch of simulations. Since Splash can produce the column density grids for me from my Gandalf dumpfiles I was hoping there would be a way to produce the PDFs as well, as I don't need the column density grids for much else. I found the grid2pdf script in the utils folder which looks like it might be what I want but it doesn't seem to be referenced anywhere else in the code or actually used. Is it meant to be used as a standalone script? Or is it a relic that is no longer implemented (I see it was edited 10 years ago)?
You also mention in the documentation that the 'calc timeaverage' could be used to get "time averaged probability density function (PDF) from PDFs produced by splash ." but again no mention of how to produce the individual PDFs.
Thanks,
Sarah
The dust-to-gas ratio for the multigrain files is not being computed correctly. Also the gas density in the single-grain one-fluid is different from the gas density in the multigrain one-fluid by a factor of the dust-to-gas ratio.
currently the fits reader assumes that the image type (32 bit or 64 bit) is the same as the real type (32 bit or 64 bit), if these do not match we end up with garbage from the fits reader
floating colour bars appearing outside plot limits don't set the page margins appropriately, meaning they get cropped
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 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.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
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.